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ABSTRACT 



Planning and controlling the software development process 
has shown, in the past, to be an extremely diffcult task. 

The estimation of resource requirements, development costs, 
risk profiles and project feasibility has often proven to be 
inaccurate, thus costing the government time and dollars. 
However, by using obtainable management parameters, and simple 
engineering and operations research techniques, estimating 
can be done easily and accurately by taking a macro approach 
to the estimation problem. 

This study will present the background and mathematical 
basis for a software cost estimation model. In addition, an 
example of an automated application of the model will be pre- 
sented and discussed. 
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I. INTRODUCTION 



A • GENERAL 

Software development within the Federal Government has 
been significantly marred by a history of projects that are 
characterized by cost and schedule overruns, and a delivered 
end-product that fails to provide the desired performance 
and function originally required. This statement is not 
mere conjecture, but has been observed and documented in the 
past. The compilation of responses to a questionnaire sent 
out by the United States General Accounting Office (GAO) to 
one hundred and sixty three software contracting firms and 
one hundred and thirteen experienced federal project 
officers has ascertained that in over 50 percent of the cases 
52.0 percent of the respondents experienced software develop- 
.ment calender overruns, 50.4 percent of the respondents 
experienced software cost overruns, and 43.3 percent of the 
respondents received software that required substantial in- 
house correction or modification prior to being effectively 
used. [Ref. 26: 8-10] 

In an industry in which the Federal Government incurs 
expenditures and fiscal obligations well into the billions 
of dollars, the process of resource estimation and project 
control for software development is a major budgetary concern 
As developm.ent costs steadily and rapidly escalate, this 
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concern gains added complexity (Figure 1) and some manner of 
formal methodology which allows the project manager to 
esrimate the resource requirements and to control the project 
becomes necessary. 

The requirements of such a methodology must allow for 
rhe capability to operate with any size project yet still 
remain a function of manageable parameters such as effort 
and development time. These parameters require relationships 
to the system size (delivered source lines of code) in terms 
of such environmental factors as: 
system complexity 

use of and type of software engineering tools 

user interface 

use of a target machine 

use of a development computer 

the development language used 

other human factors 

[Ref. 20: 14] 

In addition, the concept of system, difficulty is a factor 
that must be taken into account, not only in terms of the 
.number and types of source lines of code, but also in terms 
of the development approach and the integration of modules 
and subprograms. 

The Department of Defense (DOD) has taken steps to 
formalize and standardize the governing of the life-cycle of 
automated information systems (AIS). Life cycle management 
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Hardware versus Software Cost Trends 
[Ref. 3; 1227] 
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(LCM), as defined by the Departnient of Defense, is "the 
process for administering an AIS over its whole life with 
emphasis on strengthening early decisions which shape AIS 
costs and utility." [Ref. 5: 2] 

Among the objectives of life cycle management is to 
assure the lowest total overall cost and to provide visibility 
for resource requirements. In order that a project manager 
might plan and control a software development project through- 
out rhe entire life-cycle, he must be able to answer four 
simple management questions in terms of cost and resources: 

Is the project feasible? 

What are the resource requirements? 

How long will it take? 

What are the risks? 

Unfortunately, the past has shown that these simple questions 
can prove to be extremely difficult to answer. Not only must 
these questions be answered during the initial stage of the 
project, but also throughout the entire life of the project. 
"Software development is dynamic ... not static." [Ref. 20; 181] 

B. SCOPE 

This study is directed toward the role of the manager, 
his ability to address and answer the four managem-ent ques- 
tions, and the role of these questions in life-cycle control. 
Much of the background information is technical/mathematical 
in nature. These topics will be presented in such a manner 
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as lO allow the reader to grasp the fundamental concepts 
without unnecessary inundation by the mathematics involved. 
The emphasis will remain on the conceptual aspects and in 
the resultant numerical answers . 

The principles presented in this study are applicable 
to software development project managers both inside and 
outside the federal government. Because the Department of 
Defense is one of the largest single users of computer 
technology, this study will reflect Department of Defense 
policies and techniques . 

C. ASSUMPTIONS 

Ir is assumed that the reader has a working understanding 
of life cycle management and the software development process 

D. ORGANIZATION OF STUDY 

This study will be organized in such a manner as to flow 
from the conceptual to the specific. After the presentation 
of necessary background material in Chapter II, greater speci 
fication occurs in Chapter III in dealing with the Rayleigh 
curve, its characteristics, and its relationship to the life- 
cycle. Chapter IV will deal with the characteristics and 
application of the Putnam Software Equation. Chapter V will 
present computerized applications of this methodology using 
the SLIM (Software Life Cycle Model) software estimation pack 
age. This study relies heavily on the writings and observa- 
tions of Lawrence H. Putnam, President of Quantitative 
Software Management, Inc. 
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SUMM-^RY 



This study will present a means of answering the four 
basic management questions concerned with the control and 
planning of software development; 

Is the project feasible? 

What are the resource requirements? 

How long will it take? 

What are the risks? 

This will be accomplished in a manner which uses the basic 
management parameters of time, cost, and manpower, as the 
inputs for planning and control. 
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BACKGROUND 



II 

A. AN OVERVIEW OF LIFE-CYCLE MANAGEMENT AND THE 
SOFTWARE DEVELOPMENT PROCESS 

1 . Life-Cycle Management 

The Department of Defense subdivides the life-cycle 
of an automated information system into five broad phases: 
Mission Analysis/Project Initiation 
Concept /Development 
Definition/ Design 
System Development 
Deployment /Ope rat ion 
[Refs. 6: 2, 10: para 1003.3] 

These phases are sequential and act as a control mechanism 
for both systems development and manage.ment accountability, 
a. Mission Analysis/Project Initiation 

This phase serves to identify a mission element 
need in terms of functional requirements, validate the need, 
and recoiiunend the exploration of alternate functional con- 
cepts that satisfy the need. Although this particular 
structure exists in large projects requiring extensive 
resource commitments, the philosophy of mission need can be 
persuasive in smaller programs and should be carried out and 
documented in a like manner. This phase is completed at 
.Milestone 0, the approval of the Mission Element Need 
Statement (MENS). 



17 



b. Concept Development 

The Concept Development phase serves to define 
requirements, evaluate the alternative methods that satisfy 
the need, and to recommend one or more feasible concepts for 
further exploration. This phase terminates with approval 
for the vendor to demonstrate the alternative concepts or to 
proceed directly to the definition and design phase, given 
That one concept has been selected. Termination of this 
phase indicares Milestone I . 

c. Definition/Design 

The purpose of the Definition/Design phase is to 
fully define the functional requiremenrs in terms of system/ 
subsystem specif icarions , and to design an operable system. 
This phase terminates at Milestone II when both the defini- 
tion and design concepts have been approved. 

d. System Development 

The System Development phase serves to develop, 
integrate, rest and evaluate the system. This phase is 
complered when the appropriate functional officials grant 
approval, certifying that the system satisfies the mission 
need. .Approval constitutes Milestone III. 

e. Deployment and Operation 

This phase covers the implementation of the 
approved system, the continued operation of the system, and 
all required maintenance and modification. 
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2 . 



The Software Development Process 



There are several ways of viewing the software 
developmem; process. For purposes of this study, the soft- 
ware develop.'nent process will consist of four phases: 

Systems Definition 

Functional Design/Specification 

Development 

Operation and Maintenance 

The phases are essentially sequential, bur some degree of 
overlap can be permitted. In addition to the four phases, 
there is one step. Installation, which overlaps both the 
Development phase and the Operation and Maintenance phase 
(Figure 2 ) . 

a. Systems Definition 

Systems definition includes the complete defini- 
tion of the preferred alternatives or alternative, the 
establishment of bounds on manpower effort and development 
ti.me, and the refinement of costs. 

b. Functional Design/Specif ication 

This phase involves the preparation of detailed 
system specifications for both the application and technical 
software support, and the finalization of technical proce- 
dures and programming policies. Finally, detailed system 
specifications are converted into detailed programming 
specifications . 
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c. Development 

The Development phase can be further subdivided 
into two steps : 

Design and Coding 
Test and Validation 

These two steps include the coding of applications specifica- 
tions and the conducting of unit and string testing of the 
machine executable instructions. In addition, program docu- 
mentation is completed. System testing requirements are 
prepared and the test is carried out. 

d. Operation and iMaintenance 

The final phase, Operation and Maintenance, 
includes system refinement, tuning, post-implementation 
reviews, and the continued operation and required 
maintenance . 

e. Installation 

The installation of the system overlaps the end 
of the Development phase and the beginning of the Operation 
and Maintenance phase. This step includes implementation and 
conversion planning as well as the actual conversion and 
phased implementation. [Ref. 2: 14-18] 

3. MICRO VERSUS I^CRO METHODOLOGY 

The traditional approach to size/ time/cosr estimation 
has been the use of a micro-methodology. (Table 1) This 
methodology is largely intuitive and begins by fixing the 
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Table 1 



Traditional Methods of Cost Estimation 
[Refs. 1: 229-231, 11: 24, 27: 12-13, 29: 618-619] 

1. Experience Method 

2. Constraint Method 

3. Top-Down Estimating 

4. Similarities and Differences Estimating 

5 . Analogy Method 

6. Standards Estimating 

7. Ratio Estimating 

8. 3ottom-Up Estimating 

9. Units of Work Method 

10. Smoothing and Extrapolation Estimating 

11. Number of Instructions 

12. Quantitative Method 

13. Cost Per Instruction 

14 . Percent of Hardware Method 
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size, szart daze and durazion of each distinguishable 
activity. Adjustments are estimated and applied based on 
the caliber of personnel, complexity, and so forth. Finally, 
activities are arranged using network models such as PERT 
(Program Evaluation and Review Technique) and CPM (Critical 
Path Method). [Ref. 11: 23] To even further quantify the 
development process , the number of modules within the entire 
process, the number of statements per module, and the cost 
per statement are estimated. [Ref. 20: 13] Productivity is 
the critical input to this methodology. The major drawback 
is, however, that productivity varies greatly between 
organizations and individuals. 

The micro approach can wor.k well on small projects where 
there is little detail involved and few programmers are 
required. Troubles develop when the program being developed 
involves large volumes of detailed specifications and hundreds 
of thousands of lines of source code. 

When using traditional methodologies, most errors in cost 
estimation are a result of underestimating size, sometimes by 
as much as a factor of three. This is usually the result of 
erroneously relating productivity to delivered source lines 
of code. In addition, it is common to find a productivity 
factor that has a standard deviation two and one half times 
greater than the expected value. [Ref. 7: 2] More discussion 
concerning productivity will be accomplished later in this 
chapter as well as in Chapter IV. 



23 



The macr'o approach views the project from a higher level 
Beginning as early as the Systems Definition phase, manage- 
ment parameters serve as inputs to the methodology. The 
inputs can be used to generate rhe expected life-cycle curve 
of manpower versus time. As the project progresses and the 
parameters become firmly established, the life-cycle curve 
can be updated. Milestones can be located along the curve 
and parallel tolerance curves can be generated to indicate 
the percentage of uncertainty. Through the information 
presented along the life-cycle curve, control can be exer- 
cised over the life-cycle of the project. The key to this 
approach is that the curve can be shown in terms of manage- 
ment parameters: manpower, time, and effort. [Refs. 11: 24 

20: 130] This is the approach that will be presented in 
this study. 

C. SOFTWARE MYTHS 

Most large-scale software development projects that go 
astray do so because of calender overruns. [Refs. 5: 14, 

26: 9] Much of the problem wi.1:h overruns can be traced to 
myths that surround software engineering: 

Development effort is the product of people and time. 

Programmer productivity (source statements per unit of 

work) is constant and can be set by managemenr. 

Productivity varies directly with the effort applied. 

Men and months (time) are interchangeable. 

[Refs. 5: 14, 16: 352, 17: 348, 20: 14] 
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Develooment Effort 



The assumption that development effort scales 
l:.nearly as the product of people and time (Figure 3) leads 
one to belueve that time can be arbitrarily set by manage- 
ment and that the requisite number of people can be assigned 
ro achieve the desired results. As will be shown in the 
rollowing chapter, this reasoning can lead to both calender 
and cost overruns . 



2 . Productivity 



Traditionally, m.anagement estLmates the number of 
source lines of code and applies a historical overall pro- 
ductivity rate to determine a man-year number. For example: 
Given : 

Source Lines of Code (Ss) = 200,000 lines of code 

(estimate) 



Productivity (PR) 



Total Source Lines of Code 
Total Effort 



(historical ) 



therefore : 

Development Effort (E) 



= 1000 Ss/MY (man-years) 



200,000 



1000 



Ss 
Ss/MY 



= 200 MY 



Lawrence Putnam, during the course of his studies, 
performed a least sc__uares best fit, using data taken from 
over four hundred projects of the United States Air Force's 
Rome .Air Development Center, against delivered source lines 
of code for each of the four hundred projects. The data 
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expressed a wide range in system size (100 to 1,000,000+ 
source lines or code), project duration (one month to 6 
years + ) , man-months of effort (one MM to 20,000 MM), average 
number of people (one to several hundred), and productivity 
(10 Ss/MM to several thousand Ss/MM) . The resulting corre- 
lation coeiricient after performing a least squares best fit 
to productivity (Ss/E) versus delivered lines of source code 
was round to be r = .033415, thus displaying virtually no 
correlation. [Refs. 20: 29-30, 24: 87] 

However, after performing further least squares best 
fit relations, project duration in months versus delivered 
source lines of code showed r = .700256. When total man- 
months versus delivered source lines of code were predicted 
linearly, r was shown to equal .853915. When a least squares 
best fit was performed for the average number of people 
involved in the development effort versus delivered source 
lines of code, the correlation coefficient showed r = .80388. 
[Refs. 29: 29-30, 24: 88-90] Although standard deviations 
proved to be large , three of the variables did show good 
correlation to delivered source lines of code. Furthermore, 
it was shown that there is virtually no correlation between 
productivity and delivered source lines of code (Table 2). 

C. E. Walston and C.P. Felix, in their study, began a 
software measurement project for the IBM (International 
Business Machines Corporation) Federal Systems Division in 
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Table 2 



Correlation Coefficients (r) 

(Based on Least Squares Best Fit against Delivered Source 
Lines of Code (DSLOO) 



Correlation 
Coefficient (r) 



Productivity 

(Ss/E) 


0.033415 


Project Duration 
Time 


0 .700256 


Total Effort 


(MM or MY) 


0 .853915 


Ave . Number of People 


Involved in Development 
Effort 


0.80388 
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1372. They found twenty-nine variables that had an 
extremely high correlation with productivity, [Ref. 28: 62] 

The figures concerning these variables are tabulated in 
Appendix A. 

3 . The Interchangeability of Men and Months 

One of the largest problems associated with software 
engineering evolves from the erroneous utilization of the 
concept of the man-month. Because cost varies with the 
product of men and the number of months (time), using man- 
month as a means of measuring the size of a job implies that 
men and months are interchangeable. Unfortunately, they are 
not. .Man-month is a measure of effort. "The number of 
months of a project depends upon its sequential constraints. 
The maximum number of men depends upon the number of inde- 
pendent subtasks , " [Ref, 5: 25-26] 

If an appropriate development schedule is established 
at the outset of a project, satisfactory work can be accom- 
plished within the allotted time by the assigned programmers. 
[Ref. 11: 23] Otherwise, the oft quoted Brooks' Law takes 

over; "Adding manpower to a late software project makes it 
later." [Ref. 5; 25] 

D. SUMMARY 

Life-cycle management and the software development process 
offer a structured means for planning, developing and 
controlling the software project. Traditionally, the resource 
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esnmation process has been a micro approach. This is an 
intuitive approach which hinges extensively on the relation- 
ship between productivity and delivered source lines of code. 
Data from past projects indicates that no correlation exists 
between the two . Another erroneous assumption made in the 
software engineering field is the use of man-month as a mea- 
sure of the size of a project. Man-month is a measure of 
effort. Another estimating approach, macro-estimating, makes 
use of accessable management parameters: time, manpower, and 

cost. In order to accurately estimate the project resource 
requirements, the various software myths that manifest them- 
selves in the more traditional approaches have to be 
dismissed . 



30 



III. THE LIFE-CYCLE MANPOWER CURVE 



As previously shown, the software development process 
can be subdivided into sequential and overlapping phases. 
These phases can also be further subdivided into steps. The 
relationship between the phases within the system development 
process is such that required work for a particular phase 
cannot begin until specific work in an earlier phase is com- 
pleted. The phases display technological interdependence. 
[Ref . 13 : 156 ] 

The software development process also displays the 
traits of a homogeneous project. The development process is 
such that each phase has at least one technological inter- 
dependence tie to another phase. Otherwise, each phase 
could be considered an independent process. [Ref. 13: 156] 

A. CHARACTERISTICS OF THE RAYLEIGH xMODEL 

In the life-cycle model developed by Peter V. Norden 
during a course of study he conducted between 1956 and 1964 
at the IBM Development Laboratories in Poughkeepsie, New 
York [Ref. 12: 219], a small number of successive phases of 
work, with each phase being based upon the manner in which 
complex technological problems are approached, are mathe- 
matically fitted to a life-cycle curve. This life-cycle 
curve can be mathematically represented by the Rayleigh 
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equation, a mathematical form from the Weibull family of 
reliability runctions. The equation that describes each 
phase is: 

2 

y' = 2Kate~^ (Figure 4) 

where 

y’ = the manpower utilized during each time period 
(man-years/year or man-months/month) or the 
number of people involved in the activity at any 
given instant in time. 

K = the total cumulative manpower (life-cycle effort) 
utilized upon completion of the project (man-years 
or man-months). 

a = the shape parameter. This governs the time 
required to reach peak manpower. 

t = the elapsed time, in years or months, from the 
start of the cycle. 

[Ref. 13: 156-157] 

The Rayleigh curve appears to retain its validity only 
for an activity which requires the making of large decisions. 

A combination of phases will not result in a single overall 
Rayleigh curve. [Ref. 14: 13] This principle states that 
the summation of a series of overlapping Rayleigh curves will 
not produce another Rayleigh curve. There is, however, a 
significant observation that is termed the Software Development 
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Si^gls Cycle' Phenomenon l:hal: ignores "this additive principle, 
ine phenomenon is such that the process of software develop- 
.ment yields cycles that do add up to a Weibull shape. This 
see.ms to imply that the software development process is a 
homogeneous problem solving effort, even though the effort is 
broken down into phases. [Ref. 12: 225] This phenomenon was 
tirsr noticed by Lawrence Putnam, then with the U.S. Army 
Computer Systems Command. Its validity has since been corro- 
borated by many other studies (Table 3). Further mention of 
the Rayleigh equation/ curve will be in the context of software 
development . 

Multiplying the Rayleigh equation by the labor rate con- 
verts it to a cost function. Integrating the equation over 
tLme (Figure 5) produces cumulative effort and cost of any 
time, [Refs. 13: 158, 20: 5] 

,2 

y = K(1 - e'^^ ) 

and taking the derivitive of the Rayleigh equation (Figure 6) 

2 

y" = 2Kae“^^ (1 - 2at^) 

yields the change in the total effort at any time. [Ref. 13:158] 

The Rayleigh equation is expressed in terms of management 
parameters, in this case, time and effort, which are necessary 
for a macro-methodology. These management parameters can be 
further expressed in terms of manloading and cash flow rates. 
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Table 3 



A Sapling of Those Who Have 
round Evidence of Rayleigh-Like Behavior 
[Ref. 20: 32-33] 



Investigator 


Application 


50 .A.rmy Computer Systems 
Command (CSC) Systems 


Business 


Apollo -Gemini 


Very Large Real-Time 


NSA Syste.m 


Mixed (10-100 MY) 


Electronics Systems Division 
(ESD), USAF 


3 

Imbedded (C , Wpns Sys) 


Defense Log Mgt Agency 


Business (Logistics) 


Hughes Aircraft 


Mixed 


GTE 


Real-Time Telecomm 


Apollo-Draper Labs 


On Board Software 


So. Cal. Edison 


Small On-Line Customer 
Information System 


General Electric Factory 
Control (MICS) 


Medium-Size Process 
Control System 


Wolverton's Data 


3 

Large Aerospace and C 


Joel .Aron and IBM Yor.ktown 


Large System Software 
and Application 


Riordan's Dynamic Model 


General Systems 
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Figure 5 

Cumulative Manpower Utilization 
[Ref. 13: 158] 
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CHG IN '/. OF TOTfiL EFFORT 




TIME (years) 



Figure 6 

Change in Manpower Utilized 
[Ref. 13: 158] 
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and cimularave effort and cost. In addition, project 
delivery scnedules, in terms of project milestones, can be 
empirically located on the curve. 

It nas been determined that the shape parameter, 'a' , 
is related to software development time such that 

1 

a = 2 

? t ^ 
d 

where 

t^ = development time 

Mathematically, t^ is the time that the Rayleigh curve 
reaches a maxim.um. It has been empirically demonstrated 
that this is essentially the time that a system becomes 
operational, the development time. [Refs. 17: 352-A, 20: 17] 
For purposes of this study, it will be assumed that t^ equals 
the development time for a system. 

The relationship between development time, t^, and the 
Rayleigh equation, and cumulative manpower, K, and the 
Rayleigh equation are graphically demonstrated in Figure 7 
and Figure 3 . 

It is also interesting to note that, in Figure 5, thirty- 
nine percent of the total effort utilized takes place during 
the first quarter of the phase. Seventy-eight percent of 
the total effort utilized occurs during the first 43.5 percent 
of the phase. These figures point out the realistic time and 
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MRN-TERRS UTILIZED 




TIME (TERRS) 



Figure 7 

Change in Time-To-Peak versus Constant Manpower 

[Ref. 13: 159] 
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Figure 8 



Change in Manpower versus 

[Ref. 13: 



Constant Time-To-Peak 
159] 
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manpower requirenenlrs after development time for such factors 
as maintenance, modifications, and continued program 
management . 

3. EFFECT OF SYSTEM NOISE AInID RANDOM BEHAVIOR 

One hundred and seventy-four time history data points 

of thirty eight different systems, taken primarily from the 

U.S. Army Computer Systems Command, National Security Agency, 

and IBM - NASA, were normalized, in order to make the ranges 

comparable, and plotted. Lawrence Putnam fitted the best 

Rayleigh curve to the data, along with a ninety percent 

confidence interval, with the resulting coefficient of 

2 

determination, r , equal to .7744 (Figure 9). 

It is quite evident that there is considerable scatter 
in the data. One must consider that the process is subject 
to the laws of probability; due to less than perfect manage- 
ment, crises will appear and the size and solution become 
the probabilistic factor. In addition, it can be reasonably 
assumed that management did not respond to project require- 
ments. Also, data is not necessarily recorded in a careful, 
precise manner. [Refs. 20: 19, 24: 74] 

What allows the Rayleigh equation to be such a powerful 
management tool is that, even with considerable scatter, 
development time can be determined with an uncertainty less 
than three percent and that total effort can be determined 
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NORMALIZED TIME.t/t 



>^7ith less than nine percent uncertainty. It is now obvious 
that despite noise in the system, management parameters can 
be accurarely determined. 

C. DIFFICULTY CONCEPTS 

The ratio k/t^^ demonstrates a significant relationship 
to the Rayleigh equation. The variable dimensions of this 
ratio rexlect force, the time rate of change of momentum. 
[Refs. 16: 350, 22: 19] 3y linearizing the Rayleigh equation 
through the process of logarithms 

Lcg(y'/t) = Log(K/t e)t 

^ 2t 

d 

and plotting the equation in terms of manpower applied to a 

2 

system over time squared, with Log(K/t^ ) being the inter- 

2 

cept and 1/(2 t^ ) the slope, a straight line is produced. 

Putnam performed this operation for some one hundred systems 

2 

and round that the argument of the intercept, K/t^ , reflec- 
ted system difficulty. Those systems considered easy to 
develop had low intercept values and, conversely, those 
considered more difficult to develop had high intercept 
values (Figure 10). In terms of the management parameters, 
it is evident that cumulative manpower is directly propor- 
tional to system difficulty while development time is 
inversely proportional to system difficulty. In other words, 
system difficulty reflects programming effort and the time 
required to produce the system. [Ref. 16: 350, 20; 35-36, 

22 : 20 ] 
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log(y ' /t ) 




Figure 10 

Linear Form of the Rayleigh Equation 
[Refs, 16: 350, 20: 36, 22: 227] 
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Proxessor George J. Fix, of Carnegie-Mellon University, 
shows that the dependence of the system difficulty, D, is 
such that D is a function of time, cumulative manpower, and 
on-hand manpower. 

D = D( t ,y ,y ' ) 

This implies tnat difficulty increases with the number of 
people involved in the activity, both on-hand and cumulative, 
and time. [Ref. 8: 363] 

1 . Feasible Region 

One can visualize a feasible software region based on 
development time and life-cycle man years (Figure 11). A 
system can span from a life-cycle man-year of one to almost 
any given total number of life-cycle man-years . The develop- 
ment time can range from one month to ten years or more . 

For large systems, though, bounds must be established, there- 
by creating a development-feasible region. Development time 
can be li.mited from two to five years: five years being an 

economic upper bound, two years reflecting the lower limit 
due to limitations on manpower buildup. [Ref. 16: 351, 

20: 37, 2 ^: 115] 

Frederick Brooks alludes to this lower bound by citing 
V.A. Vyssotsky's estimates that "a large project can sustain 
a manpower buildup of 30 percent per year." [Ref. 5: 179] 
Norden's equation 

2 

y' = 2Kate~^^ 
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(life-cycle man-years) 




Figure 11 

Feasible Software Development Region 
[Ref. 20: 37] 
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r.olds lo this principle when the development time is equal 
1.0 or greater than two years. [Ref. 22: 23] The manpower 
buildup invokes Brooks' intercommunication law for those 
projects where the parts must be separately coordinated with 
the other parts. This law states that effort increases as a 
runction ox n(n-l)/2. By adhering to this law, "three 
workers require three times as much pairwise intercommunica- 
tion as two; four require six times as much as two." 

[Ref. 5: 18] Lawrence Putnam rationalizes this lower limit 
even more plainly. He says that large software projects 
less than two years in duration cannot be managed "without 
heroic measures." [Refs. 16: 351, 22: 24] 

By portraying the feasible region in three dimensions 

through the process of adding a new axis reflecting system 

2 

difficulty, k/ t^ , a difficulty surface is created (Figure 
12). It should be noted that just as in Figure 10, as 
development time is decreased, difficulty increases. 

2 . Difficulty Gradient 

Systems tend to fall on lines which correspond to a 
constant degree of difficulty on the difficulty surface. 

This constant difficulty can be expressed as 




This difficulty gradient reflects the organizational capa- 
bility while doing that type of work for which the constant 



. 10 ,000 



4000 



Difficulty 
Surface 




:<(MY) 
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(years) 



Figure 12 

Effort-Time-Difficulty Surface 
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was derived. [Myers: Ref. 30] As sysfem size increases, 
developmenl: 1:i!ue also increases in order io maintain a 
cons-ant magnitude of VD . [Ref. 15: 352] 

Putnam found, through studying all the systems of 
the U.S. Army's Computer Systems Command, that if a system 
IS entirely new, designed and coded from scratch and con- 
taining many interfaces with other systems, |VD| =7.3. If 
a system is a new stand-alone system, | VD | =14.7. If the 
system is rebuilt from existing systems where large segments 
of logic and code exist, |VDi = 26.9. Other data from IBM 
and the Rome Air Development Center has shown that for what 
Putnam calls a Composite I system, one which consists of 
independent subsystems which reflect few interactions and 
interfaces , as well as subsystem development occurring with 
considerable overlap, ]VD| = 55.0. For a Composite II 
system, which is similar to a Composite I but with minimal 
vice few interactions and interfaces, and with subsystem 
development occurring essentially in parallel, |VD| = 89.0. 
Putnam does note that as more data becomes available for 
different classes of systems, more constants are likely to 
e.merge. [Refs. 15; 352 , 22 : 3 , 24: 154] 

The values of the difficulty gradient for a particu- 
lar type of system will vary between software houses. This 
variance is based on the average skill level of the software 
house's analysts, programmers, and management. For a 
particular ki.nd of work, the values of the difficulty gradient 
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rerlect a learning curve for the software house. [Ref. 15: 
352] Because of the skill variance and learning attributes, 
one can expect an uncertainty of fifteen percent for the 
base gradient values expressed in the previous paragraph. 
[Ref. 24: 154] 

D. PATTERNS OF MANLOADING 

There is a myriad of possible manloading patterns. For 
example, they can be rectangular, trapezoidal, triangular, 
or just about any geometric shape one can think of. Unfor- 
tunately, the perceptual manpower needs of the project may 
not reflect accurately the real needs. "If management 
responds promptly to the perceived needs of the ongoing 
project, the manpower loading pattern will resemble one of 
rhe large number of Rayleigh-Norden curves possible." 

[Ref. 20: 25] 

For the example as portrayed in Figure 13, the rectan- 
gular manloading pattern, perhaps the simplist for the 
manager to implement, is shown plotted against a Rayleigh 
pattern. By applying the concept of the homogeneity of 
systems development, additional personnel cannot be judi- 
ciously applied to the project until the initial work is 
completed. The rectangular approach results in initial 
wasted effort, a lack of effort when critically needed, and 
extra effort toward the end of the project. Because of the 
lack of effort, during the critical periods, schedule 
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Manpower 




Figure 13 

R‘=»ctan^^ular Manloading versus Rayleigh Manloading 
° [Ref. 20: 26] 
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slippage results and further additional effort is required 
at the end of the project. This additional effort continues 
at the maxitiuti manpower level, thus compelling the project 
to continually impose a maximum cash flow rate and probably 
forcing a cost overrun. If Brooks' Law is adhered to, this 
additional manpower will not keep the project on schedule. 

Correctly applying manpower involves projecting an 
expected Rayleigh-Norden curve and setting control limits , 
based on the uncertainty of the initial data. As more 
information concerning manpower becomes available , the curve 
is adjusted to fit reality. The project manager is afforded 
the luxury of being able to project manpower needs , update 
his needs, and control the effort. 

E. DETERMINATION OF MAJOR MILESTONES 

Major milestones are located empirically along the 
Rayleigh curve based upon the coupling of life-cycle sub- 
cycles to the overall curve. [Ref. 20: 117] Table 4 shows 
the milestones derived by Putnam from data from the U.S. 

Army Computer Systems Command. The figures in Table 4 
display quite a range; however, given this range, should a 
project exceed the maximum time for a particular milestone, 
it should be quite evident to the project manager that there 
is a problem with the project that requires attention. The 
project's not meeting the minimum time should be a signal to 
the project manager that either he has an exceptional team, 
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Table 4 



Times of Major Milestones 
[Refs. 20: 71, 21: 140] 



Event "'■^'*■<1 
Design Certification 

First 0.235 
Expected 0.433 
Last 0.618 

Systems Integration Test 

First 0.550 
Expected 0.660 
Last 0.768 

Prototype Evaluation Test 

First 0.613 
Expected 0.800 
Last 0.990 

Start Installation/Extension 

First 0.613 
Expected 0.930 
Last 1.250 



NOTE: There is a .90 probability that t/t, will lie 

between first and last for a particular milestone. 
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his planning was not accurate , or something was accomplished 
in a cursory manner. It has been shown through data from 
several hundred systems, reflecting various development 
environments, that the relative occurrence of the four 
milestones is very stable, with respect to the expected 
value, in most organizations and environments. [Ref. 21: 140] 

It is important to remember that both the development 
time and the milestones are the most sensitive elements in 
the system development process. Milestones scale in a 
linear fashion; thus, if one is late meeting a milestone, he 
should expect to be late on succeeding milestones . Once 
behind, the project manager is not afforded the luxury of 
being able to catch up; "adding manpower to a late software 
project makes it later." [Ref. 5: 25] Realistic milestones 
must be set at the beginning of the project. [Ref. 20; 71] 
Determining the major milestones not only aids the project 
manager by functioning as a planning tool, but also is a 
means for measuring actual accomplishment. [Ref. 21: 140] 

?. SYSTEM SIZE VERSUS THE LIFE-CYCLE CURVE 

The relationship between development effort and life 
cycle effort 

S = .4K 

holds true for large systems , those systems with more than 
75,000 source lines of code. This relationship increases in 
a non-linear fashion as system size decreases. 
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For small sysiiems, "chose wi"th less "Chan 18,000 source 
lines of code, the life-cycle curve closely approximates the 
curve for the Design and Coding phase (Figure 14). Because 
"cnere is very little system overhead, the development time, 
t^, is near the end of the curve. In small systems, the 
life cycle curve reaches a peak at 

t./v^ [Ref. 20: 76] 
d 

The equation for the curve is 

2 2 

'< 

y' = t e ^ [Ref. 21: 175] 

"d 

In the range of 18,000 to 75,000 source lines of code, 
the overhead support activities (documentation, integration, 
testing, maintenance, and management activities) rapidly 
increase. Throughout the range of this transition zone, the 
life-cycle curve expands from approximating the design and 
coding curve to the full life-cycle curve. 

This range of system size requires an additional para- 
meter in the solution process which makes the solution 
extremely complicated. The solution involves complex 
engineering mathematics and is well beyond the scope and 
intent of this study, however, the solution has been auto- 
mated and is included in the SLIM (Software Life Cycle 

Model) software estimation program. SLIM and its 
functions will be discussed in Chapter V. 
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Figure 14 

The Life Cycle Curve versus System Size 
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G . SUMi'-L^lRY 



The curve resulting from the Rayleigh equation 



y' 




2 

-t'/2t^^ 



can be used to represent the life-cycle of a software project. 
Even though system noise and random behavior can be expected, 
time and manpower can be estimated with uncertainties less 
than three percent and nine percent respectively. Linearizing 
the Rayleigh equation results in the ability to determine 
system difficulty. The creation of a three dimensional project 
feasibility area offers the ability to visualize a difficulty 
gradient reflecting organizational capability for a particu- 
lar type of work. Based on empirical data, project mile- 
stones can be located along the Rayleigh curve which can, in 
turn, be valuable as a measure of project control. 
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IV. SOFTWARE ECONOMICS: THE SOFTWARE EQUATION 



In the previous chapter, equations, relationships, and 
variables were introduced that allow the project manager to 
plan and control the software development process. Two key 
variables, life-cycle effort, K, and development time, t^, 
afford the project manager the ability to generate both the 
instantaneous and cumulative manpower requirements, as well 
as the development costs, through the application of the 
Rayleigh equation. 

This chapter serves to show the relationship of K and 
t^ to the software development process. This relationship 
is expressed in a very powerful management tool: the 

software equation. In addition, the answer to the fourth 
management question 

What are the risks? 

will be addressed through the development of risk profiles. 



A. THE SOFTWARE EQUATION 

The software equation, a mathematical relationship 
developed by Lawrence Putnam, is an extremely powerful tool 
for planning and evaluating the development effort of the 
software life-cycle (Figure 15). The software equation is 
expressed as: 



Ss 



Ck 



,^ 1/3 



4/3 
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[Ref. 21: 191] 



where 

Ss = expected number of source lines of code. 

Ck = technology constant. 

t^ = development time (years). 

X = life-cycle effort (man-years). 

The mathe.matical development of the software equation will 
not be covered in this study: however, an explanation can 

be found in reference 9: page 828, reference 15: page 353, 
reference 17: page 352-B and reference 18: page 108. 

3y rearranging the software equation and applying a 
factor of .4- to reflect the development effort being 
approximately the first forty percent of the life cycle 
curve, the developmenr effort can be determined: 






.4K 



. 4(^)3 



K 




3y applying the burdened labor rate, the equation can be 
converted to a cost function: 



Development Cost = ($/M-Y) .4 



(SS)3 

Xk 



[Refs. 19: 304, 20: 7] 
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Technology Constan 



The most difficult variable in the software equation 
to grasp is the technology constant. The technology constant 
is : 

"the state of technology being applied to the software 
development; the environment in which the development 
takes place; the development equipment available, which 
in turn affects program turnaround and the time needed 
for debugging and testing; the extern; to which modern 
programming practices are incorporated into the develop- 
ment projecx." [Ref. 20: 40] 

The technology constant for a firm can be calculated 
given the delivered source lines of code, development effort, 
and development schedule of completed projects. For a new 
project, values calculated from other projects completed by 
the particular software developer can be compared against 
that which is estimated for the new project to determine if 
the new constant is reasonable. It is important to remember 
that a technology constant derived for a particular software 
house is not necessarily indicative of the technology con- 
stant for another software house. 

John E. Gaffney, of IBM-Manassas , using data from 
software development projects performed at IBM, Manassas, 
Virginia, found a correlation coefficient, r, of -0.72 
between the technology constant (Gaffney refers to the tech- 
nology constant as the development constant) and code com- 
plexity. In his srudy, code complexity is based on the 
proportion of conditional jumps in the code. This infers 
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~nar 51.3 percent of any variation in the technology con- 
stant, Ck, can be explained by the measure of code com- 
plexity. [Ref. 9: 330] 

2 . Trade-off Law 

The equation for development effort 



= 4 (^)^ 




reflects the power of the software equation; the trade-off 
law . 

3y improving the development environment, Ck increases, 
thus decreasing the development effort required to complete 
a project. 3y taking out the "whistles and bells" from the 
system and reducing the number of source statements to, for 
example, .95 Ss, cost will be reduced to eighty-six percent 
of the original cost. [Ref. 20: 7] Given a specific environ- 
ment with source lines of code and technology held constant, 

.. _ Constant 

- 4 

^d 

effort decreases as the inverse of development time to the 
fourth power. With a small change in time, a quantum change 
in effort results (Figure 16). "In software development, 
tLme is money. 3y giving a little (time), we can save a lot 
(of money)." [Ref. 20: 43] 
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Increasing Value of 
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Development Effort, Time, Technology Constant Tradeoff 

[Ref. 9: 832] 



Ir one is able to increase his technology constant 
through, for example, the purchase of a development computer 
and this increase is such that 

Ck(new) = 1.3 Ck(old) 

the manpower savings can pay for the development computer. 
Since 

Develoomenr Cost(new) = — Development CostCold 

i.s-^ 

= 1^5.5% Development Cost(old) 

A 54.5 percent savings (100.0 percent - 45.5 percent) on an 
old development cost of $1 Million would equal $545,000. 

This savings would certainly be enough to buy a powerful 
development computer. [Ref. 19: 804-805] 

3y invoking the tradeoff law, the project manager can 
effect substantial savings by improving his development 
environment, keeping the system size as small as practical, 
and by scheduling as much time as reasonably allowable for 
the development effort. [Ref. 19: 804] 

3. SIZING THE PROJECT 

In order to initiate development planning and control, 
the system size must be derermined early in the system 
definition phase (point 1, Figure 15). Because the actual 
design functions have yet to be initiated, the project 
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manager has access only to broad estimates of the system 
size; yet, this is enough to allow him to determine the 
basic economic feasibility of the project. There will be a 
tremendous degree of uncertainty in the early sizing, but 
this is to be expected. To demand pinpoint accuracy during 
system definition is an effort in futility. 

As the system definition and functional design/ 
specification phases progress, more is known about the 
system and estimates of system size become more accurate 
(points 2 and 3, figure 15). 3y the time that detailed 
design begins, uncertainty can be reduced to within the 
limits of engineering accuracy. [Ref. 21: 191] 

1 . PERT Sizing Technique 

Sizing will be performed using PERT (Program Evalua- 
tion and Review) sizing techniques. Expected system size is 
determined by: 



Expected Ss 



a -i- 4m b 
6 



where 

a = smallest possible system size 
m = most likely system size 
b = largest possible system size. 

This equation is an estimation of the expected value of a 
Beta distribution and skews the value toward the most 
uncertain side. 
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ror the first sizing attempt, during the system defi- 
nition phase, such a wide range of uncertainty exists that 
a sLmple average will suffice such that 

Expected Ss = ^ ^ 

The standard deviation is determined by the standard 
deviation of the Beta distribution of system sizes: 




This is the range in which 99 percent of the values are 
expected to occur divided by six. Therefore, the system 
size will equal 

Ss = Expected Ss _+ aSs. 

Statistically, there is a fifty percent chance that the 
system size will fall on either side of the expected system 
size. There will be a sixty-eight percent certainty of the 
system being within one standard deviation of the expected 
system size, ninety-five percent certainty that the system 
size will be within two standard deviations, and 99 percent 
certainty that the system size will be within three standard 
deviations . 

The sizing process is demonstrated in the following 

example . 
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2 . PERT Sizing Example 

Early in the system definition phase, the project 
manager is given the following estimates of system size; 



Function 


a 


m 


b 


Module 


1 


76000 


90000 


117000 


Module 


2 


87000 


112000 


136000 


Module 


3 


69000 


99000 


112000 



Using the PERT sizing technique, the following expected 
values and standard deviations are computed: 



Function 


Expected Ss 


aSs 


Module 1 


92167 


6833 


Module 2 


111833 


8167 


Module 3 


96167 


7167 


System 


300,167 


12836 



Expected Ss( total) is the summation of the Expected Ss of 
each module. aSs(total)is equal to 

/ £(aSs)^ . 

The results indicate that there is a sixty eight 
percent certainty that the system size will be 

300167 + 12836 source lines of code 
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The n’oinbers are rough estimates and the variance is 
extremely large; however, the project manager now has 
reasonable figures within which he can plan. 

During the Functional design phase, the project 
manager receives more detailed estimates based on further 



m.odularization of 


the system. 




Function 


a m 


b 


Module 


lA 


32075 37175 


43900 


Module 


13 


29550 32429 


38475 


Module 


1C 


18225 31582 


40900 


Module 


2A 


41875 53450 


61248 


Module 


23 


39950 47120 


55353 


Module 


3A 


27210 39805 


43715 


Module 


33 


24900 31625 


35775 


Module 


3C 


23875 29375 


34345 


PERT sizing compu 


tations reveal; 




Function 


Expected Ss 


aSs 


Module 


lA 


37446 


1971 


Module 


13 


32957 


1488 


Module 


1C 


30909 


3779 


Module 


2A 


52821 


3229 


Module 


23 


47297 


2567 


Module 


3A 


38378 


2751 



68 



Module 3B 



31196 



1813 



Module 3C 29287 1745 

System 300291 7152 

Although the level of detail is still not very great, 
an even more refined expected number of source statements is 
now available. What is even more important is that by 
further modularizing the system, the standard deviation is 
substantially decreased; in this example, the uncertainty is 
reduced by more than forty-four percent. 

C. DEVELOPMENT TIME/EFFORT DETERMINATION 

Far too often, the development time for a project is 
arbitrarily established by management. Because the develop- 
ment process is so time sensitive, 

^ _ Constant 




setting development time based on factors external to the 
project can lead to unanticipated and unwanted difficulties. 

For example, the software project in the previous section, 
in order for it to be ready for a business symposium, has a 
two year development time imposed upon it. The system is 
a new stand-alone system with the following parameters: 

Ck = 10946 

Ss = 300,000 
a Ss = 59 8 5 
$/MY = $50,000 
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Through use of rhe software equation, it is calculated 

that 

E = 514.68 man-years 
Development Cost ($E) = $25,734,009 
This resulting effort and cost is ludicrous. 

3y plotting the software equation and difficulty gradient 
as development time versus system size, given a technology 
constant of 10946 and |VD| = 14.7, a tradeoff region is 
developed (Figure 17). With the difficulty gradient imposing 
a mini.mum constraint, it is obvious that the system cannot 
be developed in two years . 

3y using the tradeoff region or substituting the diffi- 
culty gradient 

K = |VDl t^^ 

into the software equation, 

.Sss3 1/7 
"d ■ ^ |7Dl ^ 

the earliest possible time that the development can be com- 
pleted is 2.315 years or 33.8 months, almost ten months 
longer than the time that management arbitrarily set. The 
sysrem difficulty precludes a development time less than 
33.8 months. However, the project can be accomplished such 
that : 
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SYSTEM SIZE (DSLOC) 

Figure 17 

Tradeoff Between Size, Effort and Time 



33. S months 



K = 327.88 man-years 
S = 131.15 man-years 
$E = $6,557,723 

3y increasing the development time by almost ten months, a 
74.5 percent reduction in effort and development cost is 
achieved . 

3y further increasing development time to three years, 
more can be saved in terms of effort and development cost: 

K = 254.18 man-years 
E = 101.67 man-years 
$E = $5,083,261 

The application of the software equation and the trade- 
off law provides a powerful basis for a usable software 
economics relationship. This will allow the project manager 
to realistically establish time and resource requirements 
with respect to his development environment. 

D. LINEAR PROGRAMMING SOLUTION 

3ecause more than one unknown is being dealt with and 
management constraints can be applied to the development 
process, an optimal solution, either in terms of minimum or 
maximum time, can be reached by using linear programming 
techniques . 
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Constraints which can be applied to 
gramiting problem are: 

Expected source lines of code Ss = 



the linear pro- 
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contract delivery time 



budget 



$/MY(.4K) _< total amt. budgeted 

for development 



with the objective function being the software equation and 
both K and t^ being the decision variables. 



Ss 



Ck K 



1/3 



4/3 

"d 



Continuing with the previous example, the constraints 

are : 



|VD| = 14.7 (Stand-alone system) 

Ss = 300,000 

Management has realised the error of their ways and has 
established a three year development time and an $8 million 
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developmsnx budget. It has also been determined that a 



mini.mun of thirty people and a 
be available at peak manning. 

maximum manpower available 
minimum manpower available 
ma X imum time 
maximum budget 



maximum of eighty people will 
Further constraints are: 

_< 80 people 

^ 30 people 

j< 3 years 
< $8M 



In order to fit the linear programming model, the con- 
straints and objective function must be linearized. By 
applying logarithms, the objective function and constraints 
become : 

objective function: 
minimize 

1/3 log K + 4/3 log t^ = log Ss - log Ck 
subject to: 
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Graphically applying the objective function and the 
constraints results in Figure 18. Because the constraint on 
the number ot source lines of code is graphically parallel 
to tne objective function, there will be an infinite number 
ot solutions with the minimum time/maximum cost and maximum 
time/minimum cost solutions bounding a feasible region along 
t.te source lines of code constraint. In this particular 
exa.mple , t^ and D limit the solution and affect the following 
optimal solutions: 

t^(years) K(MY) E(MY) ^ 

min time 2.82 327.8 131.2 $6,557,723 

min cost 3.00 254.2 101.7 $5,083,261 

The manpower constraints do not, in this instance, effect 
the solution, but altering the manpower constraints could 
resulr in a totally different optimal solution. 

A tradeoff region lies between t^ = 2.82 years/K = 327.8 MY 
and t^ = 3 years/K = 254.2 MY on the objective function. 
Clearly, by altering any of the constraints, new optimal 
solutions can result. Yet, given the constraints of this 
particular example, the solution is more sensitive to develop- 
ment time as the difficulty gradient imposes the upper bound 
and cannot be changed. 



75 



K(MY) 




I > H / 1-^ ' > » V II 1 I iv . ■ i: I <1 

1 2 3 456789 10 

(years) 



Figure 18 

Graphical Linear Programming Solution 
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RISK PROFILES 



The life-cycle curve is not a single line, but a line 
with a bandwidth about it (Figure 9). All the variables of 
rhe software equation are subject to some degree of uncer- 
tainty and the project manager must have a means of taking 
this into account in an effort to develop risk profiles. 

Already, a degree of uncertainty has been established 
for the difficulty gradient in Chapter III [Ref, 24: 154] and 
for source lines of code . Allowing for a standard deviation 
of fifteen percent of the base value of the difficulty 
gradient, | VD | = 14.7, and for aSs = 5985, as per the previous 
example, the following equations can be solved similtaneously 
about the mean, and within cr| VD | and aSs: 

,.1/3 4/3 Ss 

^d ■ Ck 




[Ref. 20: 59] 



3y solving these equations several thousand times on a 
comtuter, K, aK, and tt^ can be determined. 

Management has decided to work toward the minimum cost 
solution 
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= 3 years 

K = 254.18 man-years 
E = 101.67 man-years 
$E = $5,083 , 261 

and, after performing a simulation, arrives at the following 
values : 

/\ 

t^ =3 years 

at^ = .25 years 
/\ 

K = 252.0 man-years 
aK =20.4 man-years 

Risk profiles can now be graphically established for both 
development time and effort using normal probability graph 
paper . 

Using the hypothetical example, to establish a risk pro- 
file for development time, the expected value, 36 months 
(three years), is plotted at the fifty percent probability 
level (Figure 19). Below this plot, at the sixteen percent 
probability level, one standard deviation, 3 months, is 
marked off. Because the scale of the paper straightens out 
the normal probability integral, only these two points are 
required to plot the graph. [Ref. 22: 34] 

The risk profile for development time shows a ninety 
percent confidence interval between 32.2 months and 37.8 
months. The project manager can be assured that there is a 
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Probability That Development Time Will Re Mor’e Than 
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Probability That Development Time Will Be Less Than 



99 percsnc certainty tnat the project will not exceed forty- 
three nionths , barring external interruptions to the existing 
development environment. 

Likewise, a risk profile can be determined for life-cycle 
etfort, K, (Figure 20) and given an average burdened cost, 
this can be easily converted to a life-cycle cost risk profile . 
Also, risk profiles can be developed for development effort 
and development cost. 

F. SUMKARY 

The economics of software can be expressed through the 
mathematical relationship known as the software equation: 



Ss 



Ck 



^ 1/3 



4/3 



The software equation is a very powerful managment tool 
which mathematically reflects important economic and be- 
havioral characteristics to all those concerned with the 
software project. 

The software equation reflects the time sensitivity of 
the development process . Time cannot be changed without 
changing effort. 

Each software project has an associated minimum develop- 
ment ti.me. Completed development cannot be expected to 
occur prior to this minimum time. Knowing the minimum develop- 
ment time and its uncertainty gives the project manager a 
framewor.k from which to plan and control the software 
development process. 
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Probability That Life-Cycle Effort Will Be More Than 
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Probability That Life-Cycle Effort Will Be Less Than 



The rrade-off law is an extremely powerful tool which 
offers the project manager the opportunity to save money by 
allowing more Lime for the development process, changing the 
development environment, and eliminating the "whistles and 
bells" from the project. 
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V. SLIM: AN AUTOMATED APPROACH 



A .’nethodology which permits the project manager to 
answer the four management questions 

Is the project feasible? 

What are che resource requirements? 

How long will it take? 

What are the risks? 

has now been mathematically shown. Applying the techniques 
by hand is, at best, a tedious and time consuming chore. 

The process has been automated by Quantitative Software 
Management, Inc., and is available through American Manage- 
ment Systems, Inc. The Department of Defense has taken an 
interest in this particular methodology and has contracted 
the services of this automated software estimation package 
as well as an instructional package as per Government 
\ Contract MDA903-81-D-0062 (Appendix B). 

This chapter will be devoted to the SLIM (Software Life 
Cycle Model) package, what it does, its weaknesses, and what 
it can do for the project manager. 

SLIM "is a versatile, highly flexible software system 
that is designed to help software managers and analysts 
estimate the cost, .manpov;er, and time to build" software 
systems. [Ref. 25: 1-1] All outputs are in terms of usable 
management parameters . 
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SLIM automates three functions (Table 5). The Estimate 
function has various options (Table 6) which allow the user 
to design tne system development process , update an ongoing 
development process, and validate vendor proposals. 

A. SLIM EX.A1^PLZ 

Perhaps the easiest method to fully explain SLIM is to 
demonstrate the power and flexibility of the system through 
an example . 

1 . Scenario 

The software project 'Thesis Example' is a rebuild, 
business application, system. The project has just entered 
the functional design phase. The project manager, in order 
to update development plans, wishes to use SLIM given the 
following constraints: 

Development time: 42 months 

Development begins: January 1983 

Maximum budgeted cost: $5.5M 

Maximu.m number of men available at peak manning: 6 0 
.Minimum number of men available at peak manning: 30 
Average burdened labor rate ($/MY): $50,000 

Cost of Capital: 10% 

In addition, the following is known about the system 

development environmenr; 

Percentage of on-line development: 100% 

Percentage of the development computer dedicated 
to the development effort: 80% 
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Table 5 



SLIM Functions 



Calibrate Is used to obtain historical data from the user. 

This data will be translated internally into a 
"State of Technology" factor for the user's 
organization. It is then used to calibrate the 
model to the way a particular organization 
typically develops software. 

Editor Allows the user to interactively create a data 

file describing a new software system. 



Estimate 



Is used to obtain cost, schedule, and manpower 
estimates once a data file has been built. 



3ye 



Is used to end the current session. 



I 
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Table 6 





SLIM Options 


LINEAR PROGRAM 


- This function uses the technique of 
linear programming to determine the 
minimum effort (and cost) or the 
minimum time in which a system can 
be built. The results are based on 
the actual manpower, cost, and 
schedule constraints of the user, 
combined with the system constraints 
described earlier to yield a con- 
strained optimal solution. 


NEW TIME 


- SLIM will automatically determine the 
minimum time schedule for which 
development of your system is feasible 
This function may be used to set an 
alternative schedule for development. 

A new corresponding cost will be 
provided . 


DESIGxN TO COST 


- This function is used to allow the 
user to set a new level of effort and 
cost for development. A new time 
schedule will be generated. 


PERT SIZING 


- This technique is used to generate 
the best estimate of total source 
statements and the associated stan- 
dard deviation. 


TPvADE-OrF ANALYSIS 


- This is a very powerful technique 
which allows the user to compare the 
costs and manpower necessary to build 
a system over various time scheudles. 
This analysis demonstrates the extreme 
time sensitivity of developing soft- 
ware - as time decreases, the costs 
go up dramatically. Also, a minimum 
feasible time schedule is shown, indi- 
cating that for the size and type of 
system is shown, indicating that for 
the size and type of system described, 
a shorter time schedule simply cannot 
be imposed upon it. 
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Table 6 conxinued- 



FRONT-END ESTIMATES 


- This function provides low, average, 
and high estimates of the time and 
effort required for the feasibility 
study and functional design. 


MAN LOADING 


- This function is based on a monte 
carlo simulation of total manpower 
and time. Projections of the mean 
number of people (and the standard 
deviation) on a month-to-month basis 
are provided. These projections are 
based on an optimal application of 
resources throughout development. 


CASHFLOW 


- This function is based on a Monte 
Carlo simulation of manpower, time, 
$/MY, and inflation rate to provide 
projections of the expected cashfloiv 
on a month-to-month basis throughout 
development . 


LIFE CYCLE 


- This function provides a table of 
expected manpower and cashflow over 
time throughout the operations and 
maintenance phase. 


RISK ANALYSIS 


- This function determines the proba- 
bility of developing a system within 
a specified time or for a specified 
cost . It is very useful for strategic 
planning purposes, by providing the 
risk associated with various time S 
cost decisions. 


BENEFIT ANALYSIS 


- This function computes the benefit of 
your system in $/year required to 
amortize the cost of development and 
maintenance. It is based on the 
anticipated economic life of the 
system as well as the average rate of 
return for your organization. 


MILESTONES 


- Based on a predetermined total develop 
ment time, this function provides a 
realistic schedule for the major 
milestones of the project. 
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Table 5 continued- 



CPU USAGE 



DOCUMENTATION 



ALL ANALYSES 



:nd 



- This function provides a table of 
expected machine usage over the life 
cycle of the system, along with an 
estimate of total machine hours 
required for development. 

- Based on the total system size and 
data from hundreds of similar soft- 
ware systems, a range of expected 
pages of documentation is given. 

- This function calls all of the above 
functions automatically except 

•'•new time" and "design to cost*. If 
a complete analysis of a system is 
desired, it is recommended that you 
use *new time* or *design to cost* 
to set your desired schedule, and 
then call *all analyses* for a com- 
plete analysis. 

- This command may be used to return 
to the SLIM system monitor. 
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Percentage of system coded in a high order 
language (HOD; 100% 

HOL used: COBOL 

Percentage of the target machine's memory 
utilized by the system; 50% 

Percentage of real-time code; 0.0% 

Technology factor that has been calibrated; 9 

In addition, modern programming practices will be used 
extensively except that there will be no chief programmer 
teams. The project personnel are very experienced in terms 
of skill and familiarity with COBOL; however, they have only 
an average experience with the development computer and with 
a system of this size. 

The technology factor was derived using the Calibrate 
function and historical data. The difference between the 
technology factor and the technology constant will be dis- 
cussed later in this chapter. 

2 . SLIM Application 

Given the previous information, the project manager 
can call on the Editor function to build a file for the 
project . 
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It should be noted that a technology factor, vice a 
technology constant, is required for SLIM. By using two 
fibinacci sequences (0,1, 1,2, 3, 5, 8... and 0,2,2,4,6,10...), 
technology constants are internally assigned a technology 
factor. [Ref. 24: 153] In this example, the technology 
factor of 9 equates to a technology constant of 5168. 

SLIM offers a very powerful tool for firms lacking 
the historical data necessary to calibrate. A default value 
of 0 for the technology factor signals SLIM to select a 
technology factor. This is accomplished by taking the mean 
technology factor of the Rome Air Development Center and 
adjusting it in accordance with the answers supplied while 
using the Editor function. 

Now that a file is built for Thesis Example, the 
project manager would want to use the Estimate function to 
make pertinent cost, manpower, and time estimates. 
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RVRILhBLE ^^UnCTIOrr: hPE: 

CRLIBPhTE 

EI'ITC-- 

EBTIMRTE 

BYE 

FUnCTICrf*^ EBT 

INPUT FILENhNE” thebi: 



INPUT DRTR CHECK - 



^UMMhPV GF input DRTR printed 'Y GP rO'T Y 



CUMMRkv r=: INC nr 



CYCTEM: THEII: EXRMPLE DmTE: IE-'ep-SI 

PROJECT CTFiPT: ix-B 

COwT elenent: 





5 0 0 0 0 . 


INFLmTIDN RhTE 


. 1 0 0 


CTD DEV <1; rrv ' 


5000. 






ENVIC‘ar<^1EfHT 








ONLINE IE’”’ 


1 . 0 


HOL UCRGE 


1 . 00 


DEVELGPNEr^T TIM 


E 0 . S 0 


PRODUCT I DM TIME 


0 . E 0 


LRN'BURCE 


COBOL 






r/CTEM 








TYPE Bu: iriEc: 


MPPLICPiTIOr^ 


PERL TIME CODE 


0. 0 0 


LEVEL 




UTILIIRTIDN 


0 . 5 0 


MODEPri c-c-QupHMhiTri 


E pprctice: 






:^TPUCTljPED P«=CE 


5 


DEZIGN.'COrE INIP 


< 


TOP-DGi.sN DE’-'ELC 


pment b 


CHIEF PPObPRMMEP TERM I 


1 


EKPEPIENCE 








HVEPhll 


3 


SYSTEM type 




LMfi’rU’^'j' E 




HHPtil.lRPE 


E 



TECH.NCLCC'r 

FhCTO^ 
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♦♦ ♦ ♦ ♦ ♦ ♦ ♦♦ ♦ ♦ 



title: 



::iMijLMTiari 



e::-.hmpl£ 



DhTE: 1E-:ep-.'?1 



♦♦♦ winULHlIuM PUNhir^'S - PLERiE ^^HIT ♦♦♦ 



SYSTEM SIZE •; STMTS ' 

MINIMUM D£VELQf=M£NT TIME *MGNTH:::' 
DEVELOPMENT EFFORT •: MhNMONTHS;> 
DEVELOPMENT COST TlOno.' 

ojninflrted dgllhp:.' 

<INFLRT£Ii DDLLRP:.:* 



MEnri 

143££5. 

31 •£ 
3311.4 

9314. 

1042b. 



STD DEV 




1335. 

1514. 



SENSITIVITY PROFILE POP MINIMUM TIME 
'EXPECTED VhLUES OF TIME- EFFCp*^^ Rf^^' COST FOP 



SCLUTIOr^ 
VRP I □US S 



TEM size::* 



soupce stmt: month: 



MRr^MONTHS COST • X h 1 0 M 0 * 



<-S SD”' 


134429 . 


39. 3 


1851 


r-1 SD- 


1 S«S9E 0 . 


SO. 5 


3094 


MOST LIKELY 


1 ^ ”;22^ , 


51.3 


321 1 


SD* 


14R430. 


31. 7 


3343 


•: + S SD * 


1 E3 03 1 . 


33. y 


3599 



1 0 



M CONSISTENCY CHECK 



TOTRL MRrJMONTbT - 
PROJECT S'L-Ph'^ I or* 
hVh PEOPLE ' 
PRODUCT IV ITV • 



MITH DRTh from 



3311 . ' 

SI. 3 month: 

71. < 

E5. LirrE:.-'MM;> 



other systems of the srme size SHOUS: 



RPEh I £P THRN r^DPMRL bPFDPT 

MI thin r^GPMRL PRrii”E 

GFERTEP ^HRN NDPMhL - OF PEOPLE 
LESS THRN NOPMRL PRODUCTIVITY 
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-£• iin ^ i.n oj 



Output IS based on PERT sizing and the software 
equation. The srandard deviations are extremely important. 

Not only do “he standard deviations indicate a range about 
tne expecred value, but they also offer a device for testing 
system sensitivity. All simulations are run by generating 
random variables within the given standard deviations and 
making use of Monte Carlo simulation techniques. 

It should be noted that the consistency check indi- 
cates abnormalities within the project that will have to be 
considered. This consistency check is done against the data 
base of the Rome Air Development Center. 

Given a minimum development time of 31.2 months with 
a development effort of 2211.4 man-months, the staffing of the 
development effort, the time of the major milestones, the 
front-end estimate, and a risk analysis should be examined. 

The front-end estimates are based on historical data 
of system size versus feasibility study time and effort, and 
system size versus functional design time and effort. Data 
used for this option comes from IBM-San Jose. The project's 
development curve is determined and SLIM, in effect, extra- 
polates backwards to derive the front-end time and manpower 
requirements. Using system size to estimate the front-end 
is certainly an unscie.ntif ic method, hence the large uncer- 
tainty bounds. Yet, there is no other feasible means of 
estimating the front-end of a project but through historical 
data. Given the uncertainty bounds, this method is quite 
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satisfactory. Front-end estimation is an important option 
and is one the project manager would be wise to use; the 
front-end can incur roughly fifteen to twenty percent of 
the life-cycle cost. 
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MRfiLQHDIrib 



TITLE: the:i: e;:mmfle 



DATE: lE-"e=-81 



THE TABLE EELDM THOi'ir THE AEAA JECTED EFrOPT 
AMD ASIOCIATED ■- QP -■ ITAMDAPD DEVIATIDM PEOUIPED 
for DEVELOFmEMT. THE IMPUT PAPAftETEPT APE: 



MEAM TTD DEV 







DEVELOPMENT EPPOPT 


MM^ 3211.4 


227.3 








DEV’ELQPMEr^T TIME ‘.MDr<TH:;« 51. B 


0. 9 




IMULATICM c-ljMMlr(H - PLEATE 


UR IT ♦♦♦ 








time 


='EOPLE MCMTH 


:TD DEV 


CUMULATIVE 


CUM 










mammomth; 


3TD DEV 


JAM 


Cj T; 


3. 


0. 


5. 


0. 


FEB 


O •• 


•Zt ^ 


1. 


12. 


1. 


MhP 


3* 


14, 


2. 


2G. 


5. 


HPP 


■55 


30. 


? 


4G. 


CJ 


MhY 


G5 


EG. 


3.* 


72. 




jur< 


-* -* 


31. 


4. 


1 03 . 


11. 


JUL 


■- 5 


^ 1 » 


4. 


140. 


14. 


RUG 




4ii. , 


CJ 


132. 


19. 


Z£P 


B5 


47. 


G. 


230. 


24. 


□CT 




53 . 


G. 


283. 


29. 


NOV 


Zf Z‘ 


•?s. 


7 . 


340 . 


35 . 


DEC 


■I* o 


G5. 




4 03 . 


4c!. 


jhm 


xa 


G7 


■l! . 


470. 


43 . 


FEB 




71. 


3. 


541. 


5G. 


MRP 


G-i 


7'5. 


•9 , 


G17, 


G4. 


hPP 


9 a 


79. 


9. 


G 9 G . 


1 a • 


MhV 


O 


P: 5 . 


Q 


779 . 


3 0 . 


JUM 


G-i 


'z- < • 


1 0. 


3G5. 


39. 


JUL 


>1*4 


X 


10. 


955. 


93. 


R>JG 


G4 


9 !• . 


11. 


1 047. 


103. 


:ep 


■54 


9G . 


11. 


1143. 


113. 


□CT 


•54 


■Z4 ‘Zl 


11. 


1241 . 


123. 


tmv 


>■■4 


1 00. 


11. 


1342. 


133. 


DEC 


*• 


10 5. 


12. 


1444. 


149. 


JRM 




1 04. 


11. 


1549. 


IGO. 


FEE 


.;.cr 


1 OG. 


12. 


1G55. 


17 0. 


MRP 


.55 


lOG. 


12. 


1 7 G2 . 


131. 


RPP 


c- 


103. 


12. 


137 0. 


193. 


MRV 


5T' 


1 03 . 


12. 


1973. 


204. 


JUM 


xS- 


— 110. 


-11. 


-20c^7. 


215. 


JUL 




1 09. 


12. 


2197. 


m 


RUG 


>:5 


cjer 




Z> !■ c". !• 

L.b_ -’L. . 


iC c . 
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MhJOP '•lILcITDhE! 



TITLE: ThEir: EXhMPLE 



D!=(TE: 1E-"ep-41 



E>:i=imNi=fT IQH GF lEVEF'PL “UNDFEri lYITEM'! IHQMI. THhT EI.TIMRTE' OF THE 
MmJQP MILEITOHE- GF p ^-i^QjECT HFE VEFY ITmBLE HhD PPEIiICTHBLE. THE 
MILErTOriE: I'-OWM BELCH h=E B:H:ED CN m TQTmL DEVELCPHEHT time of 'Bl.E 

MCffTHI . 



EVENT TIME FROM BThPT TIME FC:OM ITRPT 





•:VEhPS:> 


' MCMTH: 


CPITICRL kEVIEM 


1. la 


13.4 


inTEGRRiiari teit 


1.74 


20.3 


^-POTOTYFE TE’T 


08 


24 . •? 


TThPI iMlTRLLRTICri 


E.4E 


29 . 0 


njLL QPE*^lRTICnHL CRP’RBILITV 




31.2 






FPOMT-EMD EITIMhTE: 



TITLE: ThE:i: 


: e:;rmple 








DRTE: 


12-*'ep-8 




r 

<LQM> 


I ME ‘ MDMTH:: :■ 

ve;:f-ected:> 


'..HIGH :• 


^LQM> 


EFFapT-Mri:-’ 

•EXPECTED' 


•:HIGH> : 


FEhSIBILITY 

STUDY 


7. 1 


7.3 


3 . 5 


3. 


31. 


^.5 . : 


FUMCTIOr^RL 

DESIGr^ 


5 


10.4 


11.3 


199. 


393. 


597. 
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hmhlv;:; 



TITLE: ThSIi: £:-nMPLE 



DPiTE: l£-IeF-:f;l 



THE TRBLE: belch IHQU "h? PeQShBILITV THmT IT MILL MQT TRKE MO»E THPtN 
THE IMIiICPTEIi EiMCUMT CF TIME. EFrD=T. mMIi I'QLLhFI TD DEVELDP YGUF 
SYCTEM. 



PRQEhBILITY 


TIME '^MDriTHS) 


1. 


... 


£8. 1 


C- 

• 




£8. r 


1 0. 




30. 0 


£0. 




30. 4 


30. 




30. 7 


40. 




31 . 0 


50, 


'• ' 


31. £ 


60. 


" 


31.4 


?0. 




31. 7 


80. 




31.8 


80. 


•' 


• T. rv !• 
. -• 


85. 




3£ . 7 






33. 3 



PFDBFiBILITY FP'OFILE 



PROBhE 


:ILITY 


MRHMQNTHi 


COST 0 \ 31000;' 


’ IhFLHTEIi CDITO 


-i ilOOO/ 


1 . 


. 


1 63 1 . 


6130. 


68 04 . 




CJ 




1 S^^7 . 


7 034. 


7Q0C; 




10. 


• 


1818. 


7515. 


8436. 




£0. 




£0£0. 


3088. 


815£. 




30. 




£08£. 


3518. 


8633. 




40. 




£154. 


Cj y ^ *Z| 


1 0043. 




50. 




££11. 


8£14. 


104£6. 




60. 




££68. 


8548. 


1 0808. 




70. 




£331 . 


8808 . 


1 1£18. 




30. 




£^03. 


1 03 £8. 


11700. 




80. 




£5 03. 


1081£. 


1£366. 




85. 




£536 . 


11384. 


1£816. 




88. 


• 


£741. 


1 £. 2 ! 8 1 . 


1 3848 . 





FC-QEmBILITY cpCFILE 
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Knowing thar this project definitely cannot exceed 
42 cionths , the project manager can use the Design- to-Risk 
option to determine what his maximum development time should 
be in order to assure a 99 percent chance of not exceeding 
42 monrhs . If this time is greater than the 31.2 minimum 
time, the project manager has an opportunity to improve his 
oosition by decreasing effort and cost. If the resulting 
rime is less than the minimum time, he can again use this 
option, but with smaller risk options, in an effort to 
decrease effort and cost. 
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de:i'5h to pi:k 



TITLE: ThEIi: ETlHflPLE 



DmTE: 1£- 



riE:ii5N-*G-=i;i: mill cpten Identify oppQPT'jhiTiE:. to tave tioMEV usimi? the 
TP.MDE-Gi^r LFiM "O'EETP.EP mITH h IPECIP'IEri LEVEL OP PI IK' OF HOT EXCEEIiIHG H 
PEOUIFED I'ELIVEPV DHTP. PEIULTI PFE 'lEHPpPED TO THE MIHIMUN Tir-IE- MhX I MU n 

COST iolutign. the Mirar-iufi time f-hf-mmeter; hfe: 



nlHIMUM TIME •MQHTHI' 31. £ 

DEVELCFMEriT EFFORT ..M.RhMGMTHI :■ £211. 

I'EVELOPMEHT iIOIT ■ : ; £1000 ' ^ 3214. 



EMTEP YOI.IP MRYIMiJM IiEVELOPMEMT TIME IM MOMTHI. 
> 42 



IPECIFY THE hmOUHT GF pIIK Ri 'GO'riMTED I'HTH THE RBOVE 'SCHEDLiLE 
IJHICH YOU RPE "iILLIMH TO RCCEPT: 



•;R'» ‘■•'EPY HI'Fh 
•"B> HIEM 
■v:> MEDIUM 



PPCBREILITY GF MOT EXCEEDING 
?5'. PPDEREILITY OF MOT EXCEEDING 
FOX PPCERI'ILITY OF r^OT EXCEEDING 



4£. 00 MONTHS 
•*£. 00 MONTH'"; 
4£, 00 MON'''H'S 



EriTER R* £:< OF C R 



RCSLIMIhG R ='I:K CF r<OT EXCEEDING 4£. 00 MONTHS* YOUP 

E-'.PECTED '50;. LEVEL' pRpRMETEPS R='E: 









MEhN 


3TIi DEV 


MEW 


DEVELDF^EMT 


TIME aiGNTHS^ 


■39. 31 


1. 1*^ 


MEW 


riEVELDPMEMT 


EFEOPT 


372. 


9 0. 


MEW 


IiEVELCPMEMT 


cd:t -11 000 > 


3335. 


cj2*^ 



YOUP expected SRVINGS ir< CGIT BY RCC'EFTING R PPCBRBILITY OF MOT 

EXC£EDlr"3 -:£.00 MOriTHI IS '£ SSTG. 'Li '£1000;' CDMPRPED ''ilTH THE 
MlrUMUM TIMf SOLUTION. 



YOUP FILE IS UPDRTED I'.'ITH THESE MEM PRPRMETEPS. ='UM MRNLOmDIMG RND CRSHFLOl'l 
CP LIFE C'f'CLE TG SEE HOW THESE SRV'IftGS CRfl BE FERLIGED. 



102 



H CDrH;i:TEMi; 



CHECt. 



DmT!^ c-c-cn GTHEP IiTTEMt OF THE !hME CIEE :hQW::.; 



TOTAL flMhAOMTs: . 372, . IJITHIH MOPMhL PAMGE 

PPQJECT DU='=''^!CH ' 5'='. 3 MCHTHi' UITHIN hC^-mAL chhi3£ 

AVb = PEOPLE' £2. • MlTHIh ••‘iOPHAL =hHFE 

PPOIiiJCTIVITY ■ 16-*. LlhSE-'-MM ■ MITHIM fiDPMAL PAnEE 



It should be noted that given a project duration of 
39.3 Tionths , the consistency check now shows the project 
within the normal range of the Rome Air Development Center, 

Now knowing that he can plan on a development time of 
39.3 months with a 99 percent chance of not exceeding the 42 
month limit, the project manager can run the Linear Program- 
ming option to determine the time/ef fort/cost data for a 
minimum cost solution and a minimum time solution. 
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TITLE: THE:i: E-.hmFLE 



DATE: 1E-:ep- 



THIS EIJHCTIOM u:E: TECMMi-ijP qs: lIHEhF I H‘? -S I riF*LE:> ALGOPITH^I 

TU I'ETE^^TUfiE E”G-T .;=.nI: CDIT'.' THE MIHIHUM TIME IM u.iHICH 

R SYSTEM CRH ?E z'JiLT, ^-E =ECUL“^: RFE E^.EI' OH THE HCTLFiL MhhPOME=‘- CDI 
rlNI« TCHESULE CCi^ IT-A iriT’ pc ju£ \JZ£Pn CCMBir^EI* l-iITH T^E CVCTEM CDrfCT^^H I HT 
YOU HAVE P’FQ’-'IBEI* EH^^LIE? TC YIELI* h COHSTFhIHEI* CPTIMhL IOLUTIOM. 



EhTE-’ THE MAXIMUM BE ’vELCPMEHT COST IH LGLLhPS 5500000 

ENTEr MAXIMUM BEVELOPMEHT TIME IH MOHTHO B*?. 51 

EHTEP THE MI HI MUM AND M*=*XIMUM HUMBE^’ QF PEDDLE VDU 
ChH have On BCr=B RT -EHf MAHLGAIilHG TIME.- 30* c O 



TIME 



ErFGPT 



COST 'X •?.1000‘ 



MIMIMUM 

COST 



nirUMUM- 

time 



33. : MQHTW: 



35.4 mo*hth: 



MM 



13£0. MM 



5500. 



•|DUP PEmLIITIC TPADE-0*^F PEGIEH lie: BETl.iEEr^ the limits QF THE TABLE ABOVE. 
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aNTE^’PCLMTICH lri THE ”Pi=tte-CFF TPlELE EETUEEH THEIE LlnlTi: MILL PPQDUlE ALL 
PCCEPThELE rtL'F=nHTI-...F: . mould ■i'QU like to :EE h IPPiDE-aFF RNRLY'Ii MITHItl 
the:e limit; □=• ru • 



TIME 



MMtiMotfTH: i:c:t cm siooiV' 



35.4 


ro 


550 0 


36.4 


1 131 . 


4931 


37.4 


1 060, 


44 1 6 


CO 


954. 


5974 


33.5 




ic6o6 



THE ?e:ult: :hdmu iti thi: thble'chh be uied I'IIth DEiiGM-To-rn'T op mem 

TIME TO PFrtEPATE PM 'JPnPTED FILE HMD Htt EtlTIPEL'i' ■•£1,1 HPPH'C Qf COMIEeUEMT 
PECULT: fG=- MhMLCFDIHU* Crt'IHFLOM. LIFE CYCLE- fICK nMMLYCi;- COMPUTEP TIME 
HMD FPOMT EMD ECTIMmTE:. 
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DEIIbN TD CnZ^ 



TITLE: ThEli: Ei-.Hf-iFLE DhTE: IE:- I-ef -: i: 1 



:l!m hh: =’C^[]'-*iri£ri irz be:t ettimhtp df the mimimum time hhii capRESPOMDiMG 

MAXIMUM EFFC^^T ‘AMD CGIT-- TQ I.EVELOP vauF lYwTEM. THE'-IE VALUES ARE: 



MINIMUM TIME: 31.2 MCNTHI: 

EFFOPT: 2211 . MANMONThl: 

CnS T •: X 1 0 0 0 : I 3214 . 



A uPEATEP EF^^nc-T .Gp rq:T:> I.ICIJLIi PEIULT IN A VERY PISKV TIME rCHEDULE. 
HDMEVEP- if a Lai"F= EF-QPT I: IPECI'^IED 'l.lITHir^ FEA3Dr^ABLE LIMITS)* 
BEVELCPMEr^T II ITILL FEASIBLE AS LONG AS YOU CAN TAh E MCRE TIME. 

ENTER DEIIFEB EFFORT ir^ MANMONTHS 873 



. MEAN STD DEV 

NEM DEVELOPMENT TIME 'MONTHS) 39.3 1.1 

MEM DEVELOP^'ENT COST ••X SlOUU”' 3 3833. 206. 



YOLIP -ILE r: UPDATED HITH THESE NEM f-hRAMETEPS . P«JM MA^LOADIr^G AND CASHFLOM 
OR LIFE CYCLE TO SEE hO'O THESE SAVINGS CAN BE -EALIZED. 



A CONSISTENCY CHECK MITH DATA frqm QTHEF* SYSTEMS OF THE SAME SIZE SHOMS: 



TOTAL MArU-lCNTHS • 873.. • 

PRO jEC"" SiiJFATIGN • 39. 3 MONTH 

AVG :: PEOPLE' 22.' 
PFODUC^IVITV •; 164. Lir^ES.'MM' 



MITH IN NORMAL RANGE 
MITMir< NORMAL RANGE 
MI THIN NOF-MAL F-H!iGE 
MITHIr^ NORMAL RANGE 
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Having updated the file for Thesis Example, the 
project manager can now use the Estimate function to deter- 
mine the managerial information he requires to plan and 
control the project. 



rmriLDADIMi; 

♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦ ♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦ 

TITLE: thEII: E/'hMPLE DhTE: 12-: -'E: 1 



the thele belqm ihcm: ^he MEnr^ c-pajECTEn effgpt 

HMB h’IQCIhTEB CP -• ZThr^DRPD DEVInTIDf^ C'EOUIPED 
POP DEVELO«=MEra. T^E If^PUT PhPhMETEPZ RPE: 

MERr< ITD TfEV 

hevelopmemt efpcpt •rirr* 873.0 33. •? 

BEVELOPMEr^T TIME 'MOraHB:' ?.3.3 1.1 



♦ ♦♦ :iMULRTior^ PijMMiro:; - plerie mrit ♦♦♦ 
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TIME 


PEOPLE MOrtTH 


:td dev 


CUMULRTIVE 

MRNMONTHi 


CUM 

STIi DEV 


JmM 33 


1. 


0. 


1. 


0. 


-EB 83 


a. 


0. 


3. 


0. 


MRP 33 


4. 


0. 


8 • 


1. 


RPR 83 


C- 


1. 


11. 


1. 


MRY 83 


8 • 


1. 


18. 




J\J\{ 33 


8. 


1 . 


88. 


5* 


JUL 8? 




1. 


35. 


4. 


RUG 83 


11. 


1. 


45. 


5. 


:ep 83 


18. 


1 . 


57. 


8. 


DCT 83 


13. 


a 


71. 


7^ 


riDv Si 


15. 




85. 


8. 


DEC 83 


1 8. 


■p 


101. 


1 0. 


JRM 84 


17. 




1 1 S . 


18. 


FEB 84 


18. 


c. . 


1 38 . 


14. 


MRP 84 


18. 




158. 


1 8. 


RPP 84 


81. 


3. 


178. 


13. 


MRY 84 


o o 




1 88 . 


8 0. 


jur< 84 


r* T' 


3 ^ 


881 . 


8 J . 


JUL 84 


84. 


3 . 


245. 


85. 


RUG 84 


c| 


3 


888. 


D o 

^ a 


lEP 84 


88. 


3 • 


885. 


30. 


□C T 84 


87. 


3 • 


388 . 


3 3. 


NOV 84 


88. 


3 . 


348. 


38 . 


DEC 


j 


•j 


-4 1-4 

•• •' a 


38. 


Jfin x*:- 


8’?. 




4 07 . 


48.’ 


FEB 85 


3 0. 


3. 


438 . 


45. 


MRP 85 


30. 


3. 


487. 


43. 


RFP 85 


31 . 


2 , 


487 . 


51. 


MRY 85 


Z>'2> 


J a 


588 . 


54. 


jur^ 85 




4. 


581 . 


5y . 


JUL 85 


33.' 


a. 


583. 


81. 


RUG 85 




4. 


888 . 


84. 


:EP 85 


-:3 . 


4. 


858. 


8 3 . 


OCT 85 


34. 


4. 


883 . 


71. 


NOV 85 


3-^ . 


4. 


1 1 a 


75. 


DEC 85 


34. 


4. 


780. 


T*0 


jRr^ 88 


34. 


4. 


785. 


32 . 


«^EB 88 


34 . 


4. 


328. 


RS. 


MRP 36 


J4 , 


4. 


y 8-* . 


38. 


RPP 88 


17. 


C. a 


33 0. 


8 1 . 
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MR.lQP MILErTOHE': 



TITLE: the; I* e;:rmpl£ 



DhTE: 1 £-:ep -£:1 
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SLIM IS not intended for one-time use. It can serve 
the project manager throughout the life of the project. As 
esn.mates become more refined or as requirements change, the 
tile can be updated and SLIM estimates can serve to aid in 
tne updating of plans and in the control of the project. 

3. CONTRACTING APPLICATION 

SLiM can be extremely useful in evaluating vendor pro- 
posals tor software contracts. 3y requesting the development 
effort, development time, and system size of past projects, 
as well as the estimated new project size in PERT format, 
in the Request for Proposal (RFP), each vendor can be cali- 
brated and the proposals evaluated for validity. 

If the user also determines system size, even when using 
a default technology factor of 0 (zero), a best time/effort/ 
cost estimation can be made from which the vendors can be 
again be evaluated. 

As the number of clients of the SLIM estimating package 
grows (Table 7), the ability to even further validate vendor 
proposals also grows. Knowing that a vendor used SLIM to 
deter.mine his time/effort/cost estimates, the project manager 
can now verify the proposal using the vendor's SLIM inputs to 
determine the proposal's validity. 

SLIM can do much toward eliminating cost and schedule 
overruns. Hot only can it assist in project development and 
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Table 7 



1. 
2 . 
3. 

4 . 

5 . 
5 . 

7 . 

8 . 

9 . 

10 . 
11. 
12 . 

13 . 

14 . 

15 . 

16 . 

17 . 

18 . 

19 . 



SLIM Clients as of 20 June 1981 



American Management Systems, Arlington, Virginia 

Blue Cross/Blue Shield of Illinois, Chicago, Illinois 

Boeing Computer Services, Inc., Seattle, Washington 

Burroughs Corporation, World Headquarters, Detroit, 
Michigan 



Burroughs Corporation, Program Products Division, 
Radnor, Pennsylvania 

Burroughs Corporation, Program Products Division, 
.B.tlanta, Georgia 

Burroughs Corporation, Program Products Division, 

.Miami , Florida 

Burroughs Corporation, Program Products Division, 
Irvine, California 

Burroughs Corporation, Program Products Division, 
Charlotte, North Carolina 

Central Intelligence Agency, Washington, D.C. 

Computer Management, Inc., Atlanta, Georgia 

Dynamics Research Corporation, Wilmington, MA 

Federal Aviation Administration, Washington, D.C. 

Honeywell Federal Systems Operations, McLean, Virginia 

Honeywell Large Information Systems Division, Phoenix, 
Arizona 

Honeywell Process Management Division, Phoenix, Arizona 

IBM Federal Systems Division, Manassas, Virginia 

IBM Federal Systems Division, Westlake Village, 
California 

IBM Federal Systems Division, Gaithersburg, Maryland 
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Table 7 continuted- 

20. PACTEL, Ltd., London, United Kingdom 

21. Planning Research Corporation, McLean, Virginia 

22. United States Department of Defense (includes Army, 

Navy, Air Force, Marine Corps, and all Defense Agencies) 

23. Vought Corporation, Dallas, Texas 

Source: Quantative Software Management, Inc. 



116 



corvcrol, but also by allowing the user to easily determine 
which vendors are submitting valid proposals. 

C. CRITERIA FOR THE GOODNESS OF A SOFTWARE COST MODEL 

Some method of evaluating SLIM is necessary to determine 
its effectiveness as a software costing model. Barry W. Boehm 
and Ray W. Wolverton, of TRW Defense and Space Systems Group, 
have proposed nine measures of goodness as a basis on which 
to compare a software cost model. [Ref. 4: 129] 

1 . Definition 

The model must clearly define which costs it is estimating 
and which costs it is not. 

2 . Fidelity 

The estimates that are generated by the model must be 
close to actual expended costs. 

3 . Objectivity 

The model must not allow for subjective factors that can 
sway the model in any desired direction. 

4 . Constructiveness 

The user must be able to understand why the model gives 
the estimate it does. Also, the model must help the user 
understand the software job. 

5 . De tar 1 

The model must be able to easily subdivide a project 
into phases and activities . 
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6 . Stability 

The model must reflect appropriately sized output per 
unit or input . No mathematical surprises can be generated 
by the model. 

7 . Scope 

The model must cover the class of software project to 
be esti.mated. 

3 . Ease of Use 

The model's inputs, outputs, and options must be easy 
to understand and specify. 

9 . Prospectiveness 

The model must not depend on information that is not 
well known until the end of the project. It must be able to 
function in a useful manner with the information at hand. 

D. EVALUATING SLIM AGAINST THE CRITERIA 

Boehm and Wolverton suggest that this criteria is impor- 
tant in determining the utility of a software estimating 
.model. Using this criteria, the utility of SLIM can be 
assessed . 

1 . Definition 

SLIM clearly defines what it is estimating; size, time, 
effort, cost, risk, trade-offs, manpower, cashflow, code 
production, documentation, development computer time, and 
the front-end of the project. 
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Fidelity 



2 . 

SLIM has been validated against over four hundred pro- 
jects from the Rome Air Development Center and others. 

3 . Objectivity 

It is extremely difficult to sway SLIM because of the 
data constraints inherent to the problem as well as those 
management constraints serving to define the software pro- 
ject's environment. Resultant times less than the minimum 
possible time are not allowed. 

4 . Constructiveness 

SLIM is completely consistent with the underlying theory. 
In addition, it offers the user an insight into why con- 
straints are either reasonable or unreasonable. The most 
important aspect in understanding the software development 
effort is the identification of minimum time; SLIM immediately 
identifies minimum time. 

5 . Detail 

The front-end of the project is estimated in terms of 
time, effort, and manpower. System development is estimated 
in terms of t ffort, manpower, code production rate, 

risk, and budget. The Operations and Maintenance phase is 
estimated in terms of manpower, budget, cost and, risk. 
Activities are not estimated. Activities are based on spe- 
cific organization methodology and is within the domain of 
the project manager, not SLIM. 
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5 . S uabili-cy 

All output IS consistent with the exponential and quantum 
characreristics of the model. 

7 . Scope 

SLIM is applicable for all classes of software systems 
involving a group problem solving effort. SLIM is based on 
the human intercommunication within the software process. 

3 . Ease of Use 

SLIM inputs and outputs are extremely easy to understand. 
As syste.m design becomes more refined, input ranges become 
smaller and outputs become more accurate. Output is in 
terms of usable management parameters. 

9 . Prospectiveness 

SLIM is completely consistent with the amount and 
availability of information. Based on input characteristics, 
SLIM's output informs the user of the degree of accuracy. 

E. SLIM WEAKNESSES 

Although it has been shown to be a very valuable manage- 
ment tool, SLIM does display several weaknesses. 

There is a tremendous range of values for the difficulty 
gradient, |7D|, between the rebuild and composite II systems. 
Although increased uncertainty compensates for this range, 
further classification of systems within this range of 
difficulty would further enhance program accuracy. 
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SuiM can be inconsistent with current Department of 
Derense Ixfe-cycle methodology. SLIM output assumes project 
continuity. The sequence of events leading to project 
approval prior to each life-cycle milestone can lead to 
breaks in the project schedule. This inconsistency, if 
anticipated by the project manager, must be taken into con- 
sideration when planning the software project. 

?. SUMMARY 

SLIM offers the project manager an extremely powerful 
tool for managing the software development process in terms 
of planning, budgeting and control. Sizing through the PERT 
sizing technique, simulation via the Monte Carlo technique, 
linear programming, and sensitivity analysis through risk 
profiles provide an accurate time/effort/cost analysis. 

SLIM's accuracy has been validated for over four hundred 
systems spanning the entire range of system types: from 

operating systems, real-time, and scientific applications to 
the most mundane business application. SLIM can be used 
throughout the entire planning and development phases of the 
project in order to facilitate planning and control. Project 
data is easily updated so that SLIM can be an effective tool 
when requirements or constraints change. 

.-Applying SLIM to Barry W. Boehm and Ray W. Wolverton's 
criteria for the goodness of a software cost model shows 
SLIM to be an extremely viable software estimation model. 
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SLIM does display a few minor weaknesses. More system 
types need to be identified in the difficulty range between 
rebuild and composixe II systems . SLIM output can be incon- 
sistent with current Department of Defense life-cycle 
methodology. These weaknesses are minor and certainly do 
not distract from the effectiveness of SLIM as a powerful 
tool for the software project manager (Table 8). 

An extremely important facet of SLIM is that it takes 
into account the transition zone, as discussed in Chapter 
III. It is an effective tool for small, medium and large 
projects. If any two of the following four attributes apply 
to the project, SLIM can be used; 

Ss is greater than or equal to 5000 
Peak manpower is greater than or equal to 3 people 
Development time is greater than or equal to 6 months 
Cost is greater than or equal to $100,000. 
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Table 8 



Putnam's Version of the Characteristics 
or a Good Software Cost Estimating System 



1. Should have a sound phenomenological basis that relates 
to other similar, known processes and which contributes 
to understanding the software system development process . 

2. Should apply to all organizations and classes of software. 

3 . Can be adapted to any organizational structure and way 
of doing business. 

4. Is consistent with existing, known data over the entire 
size range. 

5. Can be easily calibrated or "tuned" to a specific 
organization . 

6. Accepts management constraints on time, cost, manpower. 

7 . Should have "what if" capability to specify alternative 
cost, schedule, manpower and risk conditions within 
constraint bounds. 

8. Produces bounded solution sets. 

9 . Produces accuracy bounds on all answers . 

10. Permits risk evaluation and risk specification. 

11. Should produce consistent manpower and budget implemen- 
tation plans for each time-cost-effort solution. 

12. Should be capable of adapting to anticipated changes in 
environment, technology, language, skill, complexity and 
modern programming practices. 

13. Input information is ea,sy to estimate. 

14. Gives a measurable achievement projection (rate of code 
production) . 

15. Produces a projection of life cycle time, effort, man- 
power and budget together with accuracy bounds on these 
quantities . 
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Table 3 continued- 



16. Is capable of adapxion to future (new) environments. 
Makes extrapolation into such new environments straight 
forward and relatively safe. 

17. .‘\llows partitioning into major system phases. 

18. Permits separate analysis of modules. Aggregation of 
these pieces should show when and how much "overhead 
work" (management, integration, test S validation, 
documentation) has to be done. 



reproduced this with permission of L.H. Putnam, 
Quanritarive Software Management, Inc. 
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VI. CONCLUSIONS 



Planning and controlling the softv;are development process 
has shown, in the past, to be an extremely difficult task. 

The esti.mation or resource requirements, development costs, 
risk profiles and project feasibility has often proven to be 
inaccurate, rhus costing the user both time and dollars. How 
every, by using obtainable management parameters, and simple 
engineering and operations research techniques, estimating 
can be done easily and accurately by taking a macro approach 
to the estimation problem. 

The methodology discussed in the study, as developed by 
Lawrence H. Putnam, is based on the empirical findings of 
the relationship between the software life-cycle and the 
Rayleigh curve, mathematically expressed as 

^2 

y' = 2Kate"^'^ 



The Rayleigh equaricn can be used to determine project man- 
loading, cumulative manpower, and cash flows. 

A powerful software economics tool, the software equation 



Ss 



Ck K' 



V3 



4/3 



offers the opportunity to trade-off manpower, development 
ti.me, and the development environment in order to obtain an 
optimal development solurion in terms of minimum cost or 
mini.mum time. 
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The automated software estimation package, SLIM, makes 
use or these two equations , as well as engineering and 
operations research techniques, to form an extremely power- 
ful tool for the project manager. 

SLIM and its underlying mathematical basis reflect intui- 
tive observations of the software development process: 

Each software system has its own minimum development time 

Large projects take more effort 

Complex projects require more effort and time 

Improving software development tools and techniques 
results in an improved development environment which, 
in turn, effects development in a positive manner 

A gradual growth in manpower is the most efficient 
manloading pattern 

SLIM is based on the historical data of past development 
projects which allows it to be calibrated to the development 
history of the user. In addition, it can function as a 'what 
if analysis tool so that the user can design the software 
development project based on cost, schedule, or risk. SLIM, 
being completely consistent with the criteria set forth by 
Barry W. Boehm and Ray W. Wolverton, offers the project 
manager of any software project a viable software estimation 
model . 

SLIM does, however, reflect several weaknesses: the 

necessity of identifying further system types in the diffi- 
culty range between the rebuild and composite II systems, 
and the possible inconsistency with current Department of 
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Defense life-cycle niethodology . As previously stated, these 
weaknesses do not distract from the effectiveness of SLIM 
as a powerful rool for the software project manager. 

3y using SLIM, the project manager is able to accurately 
answer the four management questions in terms of costs and 
resources : 

Is the project feasible? 

'■.i/hat are the resource requirements? 

How long will it take? 

Whar are the risks? 

Being able to answer these questions, the project manager 
can now prevent rhe mistakes of past pro jeers and accurately 
plan and conrrol the software project. 



127 



APPENDIX A 



Variables That Correlate Significantly 
With Programming Productivity 
[Ref. 28: 64, 65] 



Question or Variable 


Response Group 
Mean Productivity 
(DSL/MM) 


Productivity 

Change 

(DSL/MM) 


Customer interface 
complexity 


<i^ormal 

500 


Normal 

295 


>Normal 

124 


376 


User participation 
in the definition of 
requirements 


None 

491 


Some 

267 


Much 

205 


286 


Customer originated 
program design changes 


Few 

297 




Many 

196 


101 


Customer experience 
with the application 
area of the project 


None 

318 


Some 

340 


Much 

206 


112 


Overall personnel 
experience and 
qualif icat ions 


Low 

132 


Average 

257 


High 

410 


278 


Percentage of pro- <25% 

grammers doing devel- 153 
opment who participated 
in design of functional 
specifications 


25-50% 

242 


>50% 

391 


238 


Previous experience 
with operational 
computer 


Minimal 

146 


Average 

270 


Extensive 

312 


166 


Previous experience 
with programming 


Minimal 

122 


Average 

225 


Extensive 

385 


263 


Previous experience 
with application of 
similar or greater 
size and complexity 


Minimal 

146 


Average 

221 


Extensive 

410 


264 


Ratio of average 
staff size to dura- 


<0 . 5 
305 


0.5-0. 9 
310 


>0 . 9 
173 


132 



t ion (people /month) 
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Hardware under concur- 


- No 


rent development 


297 


Development computer 


0% 


access, open under 


226 


Development computer 


0-10% 


access, closed 


303 


Classified Security 


No 


environment for 
computer and 25% of 
programs and data 


289 


Structured 


0-33% 


programming 


169 


Design and code 


0-33% 


inspections 


220 


Top down development 


0-33% 

196 


Chief programmer team 


0-33% 


U. S 3. § S 


219 


Overall complexity 


<Average 


of code developed 


314 


Complexity of appli- 


<Average 


cation processing 


349 


Complexity of 


<Average 


program 


289 


Overall constraints 


Minimal 


on program design 


293 


Program design con- 


Minimal 


straints on main 


391 


storage 




Program design con- 


Minimal 


straints on timing 


303 


Code for real-time 


<10% 


or interactive opera- 
tion, or executing 
under severe timing 
constraint 


279 





Yes 

177 


120 


1-25% 


>2 5% 




274 


357 


131 


11-85% 


>85% 




251 


170 


133 




Yes 

156 


133 



34-66% 


>66% 

301 


132 


34-66% 


>66% 




300 


339 


119 


34-66% 


>66% 




237 


321 


125 


34-66% 


>66% 

408 


139 




>Average 

185 


129 


Average 

345 


>Average 

168 


181 


Average 

299 


>Average 

209 


80 


Average 

286 


Severe 

166 


107 


Average 

277 


Severe 

193 


198 


Average 

317 


Severe 

171 


132 


10-40% 


>40% 




337 


203 


76 



129 



Percentage of code 


0-90% 


91-99% 


100% 




for delivery 


159 


327 


265 


106 


Code classified as 


0-33% 


33-66% 


>66% 




non-matheitatical ap- 
plication and I/O for- 


138 


311 


267 


79 


matting programs 










Number of classes of 


0-15 


16-80 


>80 




items in the data base 


334 


243 


193 


141 


per 1000 lines of code 










Number of pages of 


0-32 


33-88 


>88 




delivered documents- 


320 


252 


195 


125 



uion per 1000 lines of 
delivered code 
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APPENDIX 3 



Department of Defense Memorandum 
Concerning SLIM 

The following memorandum serves to focus Department of 
Defense interest in SLIM, notify automated data processing 
users of its implications as a tentative standard Department 
of Defense methodology, and to notify users of the contracted 
training sessions conducted by Quantative Software Management, 
Inc . 
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0MPT9OLLSR 



OF THE A5015TANT SECRETARY OF DEFENSE 



WASHINGTON DC 20301 



3 MAY :98t 



MEMORANDUM FOR ADP POLICY COMMITTEE ( PROGRAI^ MANAGEMENT) 

SUBJECT: Contract Support for Standard Software 

Development Estimates 



We have been working together for some time to improve the 
Department's capability for estimating software development 
resource requirements. In 1976 a DoD working group selected 
a two part methodology. This approach has been under test 
at a large number of DoD software development centers since 
1978. 

Recently, the first part of the tentative standard 
DoD methodology entered the commercial market as an 
automated model accessible through commercial timesharing. 

I have become sufficiently impressed with the ease of use and 
the ready response to "what if" analysis, in the commerical 
version, to obtain funding for a DoD-wide license for this 
product. It is my hope that this will expedite widespread 
use of this capability. 

Under the contract which we have negotiated, OSD has paid the 
annual license fee for DoD-wide use and for four one week 
training sessions which we plan to hold at DODCI . Any 
organization in DoD which wishes to use the capability will 
write a delivery order against our contract and will pay for 
usage; training for a limited number of persons will be free 
(except for TDY costs if necessary). Additional details are 
attached . 

It has been demonstrated to my satisfaction that we can save 
large amounts of money if; 

We do not try to do the impossible, i.e., develop 
software in less than the minimum time required. 

We make informed decisions about reducing gold 
plating, i.e., focus software development on the minimum 
essential requirements. 

We optimize the application of manpower, i.e., a 
small stretch-out in schedule planned at the outset may 
substantially reduce overall cost. 

We monitor valid thresholds for deviation from plan, 
i.e., know what reasonable deviations from plan are. 
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At least one person at any activity which plans to use SLIM 
should be trained in the use of the model prior to making any 
extensive use. The first training session has been filled. 

We are taking nominations for future sessions. If you wish 
to nominate people to receive training, please provide my 
office with the name, organization and telephone number of 
those persons wishing to attend the 10-14 August session by 
30 June. Similar information should be provided by 14 August 
for the two remaining sessions which have been scheduled for 
the October-November 1981 and February-March 1982 timeframes. 
Specific dates on these sessions will be provided later. 

Your assistance in giving this information the broadest 
possible distribution would be appreciated. My points of 
contact for this effort are Mr. Robert Cooper, 695-2554, 

(AV 225-2554) and Ms. Scarlett Curry, 697-8632 (AV 227-8632). 
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GENERAL CONTRACT INFORMATION 



The contract has been issued by: 

Defense Supply Service - Washington 
Room 1D245, The Pentagon 
Washington, D.C. 20310 
Atrn: Mrs. Katie E. Moulder 

AUTOVON 227-6021 
Commercial 202 697-6021 

The Contract Number is: MDA903-81-D-0062 

The contracr is for the acquisition of an annual lease and 
license fee for unrestricted use of a proprietary software 
package, Software Life Cycle Management Model (SLIM) for all 
DoD organizations ; and for access to the model thru tele- 
processing services, also provided for under the contract. 
The software license fee has been paid by the Office of the 
Secretary of Defense. SLIM is resident on the American 
Management Services, Inc., computer systems. Teleprocessing 
services to access SLIM will be ordered via call orders to 
the contract. 

Complete copies of the contract and additional information 
may be obtained from the Contracting Officer's Technical 
Representative : 

Rob Cooper 

Assistant Director Data Automation 
OASD(C) MS DDA Fm 1A658 Pentagon 
Washington, D.C. 20301 

ACQUISITION APPROVAL 

The Office of the Secretary of Defense has approved the 
acquisition of this capability for software development 
organizations, organizations that monitor contract software 
development, and audit or cost estimating organizations. 

A delegation of procurement authority has been obtained 
which covers all DoD activities of the type described above. 
A "2068" has been processed thru GSA to obtain Sharing 
Program approval. Any further action of this type will be 
taken by the COTR if it appears necessary as a result of 
unexpected growth in DoD wide usage of the contract. 

3y virtue of the actions described above, potential users 
within DoD have the authority to issue call orders through 
their own acquisition activity for use of SLIM, subject to 
local fund availability. 
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Call orders which exceed $10,000 should be coordinated 
telephonically with the COTR prior to issuance to facilitate 
planning . 

ORDERING INFORMATION 

Orders may be issued under this contract from 1 May 1981 
thru 30 April 1982. Information concerning renewal of the 
contract will be furnished at a later date. 

Orders should be issued thru properly executed DD Form 1155 
and mailed ro : 

American Management Systems, Inc. 

1777 Kenr Street 
Arlington, VA 22209 

Two copies of each call order will be sent to the COTR. An 
Installation Representative (IR) will be designated by each 
ordering activity. The ordering activity should provide 
Defense Supply Service Washington with the name, mailing 
address, and telephone number of the IR. The name and 
address of the IR will also be cited in the call order* so 
that invoices may be forwarded to the IR for certification 
of receipt of services. The call order shall site the 
cognizant paying office. IR's will certify and approve 
invoices for payment and forward them to the paying office. 

*31ock 14 DD Form 1155 

PRICING INFORMATION SUMMARY 

(These are GSA/TS? prices. Reference should be made to the 
contract for more detailed information) 

Remote Ter.minal Connect Charges 



Washington, DC Metro Area 
1200 baud 



Prime Hours 
$7 . 00/hr 



Non-Prime 
$4. 00/hr 



Outside V/ashington, DC 
up to 1200 baud 



Communications Charges 
TELENET 



$7. 00/hr $4. 00 /hr 

Plus communications charge 

$7. 00/hr $7. 00/hr 



CPU Utilization Charges* 
DECSYSTSM-20 



$ .ILi/RU 



$ .08/RU 



A 50% surcharge will be added to the CPU costs. 
RU = Resource Unit 
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rile Storage Charges 
(Permanent) 



1-1000 pages 
1001-2000 pages 
2001-4000 pages 
Over 4000 pages 



$ .6 4/page/ mo 
$ .39/page/mo 
$ .2 6/page /mo 
$ .18 /page/ mo 



ESTIMATING CALL ORDER COSTS 

A rudimentary method for estimating the cost of using SLIM 
is to estimate the number of manhours available to operate 
the model, e.g., 2 people X half a day X two days per week 
equates to 16 hours per week, assuming the people don't work 
together on one terminal. Costs per hour can be expected to 
range between $15 and $75 per hour. The variance between 
these amounts relate to the sophistication of the users and 
the amount of detailed printing of schedules, etc. Costs at 
the high end .may indicate that a greater benefit is being 
obtained . 

TRAINING INFORILATION 
Instructor: Mr. Lawrence Putnam 

Training Vendor-: 

Quantitative Software Management (QSM) 

1057 Waverly Way 
McLean, Virginia 22107 
(703) 790-0050 

'•The training vendor will certify attendance and course 
completion for ad.ministration purposes not for billing - 
training organizations are not billed, as the courses have 
been prepaid by OSD 

Location of Training Site: 

DoD Computer Institute 
Building 175 
Washington Navy Yard 
Washington, D.C. 20374 

Length of Course: Five (5) days 

Course Cost: Tuition - paid by OSD, no cost to trainees' 

organi zation 

TDY - paid by trainees' organization as 
required 
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The following documentation shall be furnished to each 
trainee : 

SLIM Users Guide 
AMShare Users Guide 

Tutorial Test, "Software Cost Estimating and Life Cycle 
Control; Getting the Software Numbers," IEEE Cat No 
EHO 155-1 

Booklet, "SLIM" - Sample Output 

Folder, QSM, Schematic Diagram of Software Life Cycle 
Methodology 

Student workbook containing exercises and examples in 
use of SLIM and AMShare 
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